From nobody Thu Jun 1 01:19:07 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52025129512 for ; Thu, 1 Jun 2017 01:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jcd0dRKadfvv for ; Thu, 1 Jun 2017 01:19:04 -0700 (PDT) Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (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 CA3A6129501 for ; Thu, 1 Jun 2017 01:19:03 -0700 (PDT) X-AuditID: d9a97916-f03ff7000000b01e-6e-592fcdf51b8f Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id D2.1B.45086.5FDCF295; Thu, 1 Jun 2017 10:19:01 +0200 (CEST) From: Fioccola Giuseppe To: "Brian Trammell (IETF)" , IETF IPPM WG Thread-Topic: [ippm] WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2Vzpj3BlOYX4YUisNIH+0MLyVqIPo09Q Date: Thu, 1 Jun 2017 08:19:00 +0000 Message-ID: <84439d81137d4f149012965b01ef4e84@TELMBXB02RM001.telecomitalia.local> References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> In-Reply-To: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.254] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsXCxfdHWvfrWf1IgwtLZSw2trxjs+h58I7Z gcljyZKfTB5P9s9kCWCKamC0SczLyy9JLElVSEktTrZVcsksTs5JzMxNLVIISc1JTc7PVVLI TLFVMlZSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+uhYWppa6 hkp2gaWpxSX5CrmpxcWJ6emZ+QqpCesFMx7feMFcMJu9omnfCcYGxnesXYycHBICJhJTth5m 7mLk4hASmMok8fXhY2aQBJuAjcTBVyfYQGwRAR+JriXv2UFsYQFjib3bFrJDxE0lZn9ZxQph G0l8fn4AzGYRUJE49fErkM3BwSsQKLFxsTxIWEjATuJXVxsTiM0pYC+x8PF/FhCbUUBWYsLu RYwgNrOAuMSL6SfYIW4TkFiy5zwzhC0q8fLxP6ibDSS2Lt3HAmErSlxYfhTKlpFYeGQyK8Qc PYkbU6ewQdjaEssWvgabwysgKHFy5hOWCYyis5Csm4WkZRaSlllIWhYwsqxiFM2tMDDSK4FE WWZJYk5mol5mySZGYFK4ubJSbAdj61rnQ4wCHIxKPLx79+pHCrEmlhVX5h5ilOBgVhLh5asE CvGmJFZWpRblxxeV5qQWH2L0AQbYRGYp0eR8YMLKK4k3NLGwNDS2sDAytDAzxSGsJM474b5e pJBAOjBNZaemFqQWwYxj4uCUamBs5vjssEeiuSTrW0y+Vt9JC8WlCVy2z2d1tBt7a4q8fzG1 NiXp9tJkR7kyl9l2NzcxPMiOjvZrkA6Q/rz3wt05XDW37Uxc50nM3XpQfYPKj12JNaqLtX/4 5BQ5vZXvtet3U4oTnnQ/gD/pYITWwiP8Gt82B22cM0lav6Ugs1pIeuuJ3V8fxymxFGckGmox FxUnAgC4WxUONwMAAA== Archived-At: Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jun 2017 08:19:06 -0000 Hi IPPMers, First, I want to thank IPPM chairs for starting WGLC phase. I think the document is stable and consolidated in terms of content and scop= e. I support its publication (as co-author), also because there are related use= cases, already presented within IETF, that need a reference document. Best Regards, Giuseppe -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Brian Trammell (IETF) Inviato: marted=EC 30 maggio 2017 17:53 A: IETF IPPM WG Oggetto: [ippm] WGLC on draft-ietf-ippm-alt-mark Greetings, IPPM, As discussed in Chicago, this message begins a Working Group Last Call on dr= aft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday 20 June 2= 017. Please reply to ippm@ietf.org indicating whether you believe this docum= ent is ready for publication, and if not, why not. Many thanks, best regards, Brian (as IPPM co-chair) Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. From nobody Thu Jun 1 10:42:02 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE9C12F27B for ; Thu, 1 Jun 2017 10:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 nwyS4it2RUWE for ; Thu, 1 Jun 2017 10:41:58 -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 5DCC612F26D for ; Thu, 1 Jun 2017 10:41:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHS69033; Thu, 01 Jun 2017 17:41:56 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 1 Jun 2017 18:41:55 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.56]) by SJCEML702-CHM.china.huawei.com ([169.254.4.117]) with mapi id 14.03.0235.001; Thu, 1 Jun 2017 10:41:52 -0700 From: Alexander Clemm To: Fioccola Giuseppe , "Brian Trammell (IETF)" , IETF IPPM WG Thread-Topic: [ippm] R: WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2q/J3Q6IJVI0oUq1vAuoAJcFWqIQRT/w Date: Thu, 1 Jun 2017 17:41:52 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DFB2D55@SJCEML701-CHM.china.huawei.com> References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> <84439d81137d4f149012965b01ef4e84@TELMBXB02RM001.telecomitalia.local> In-Reply-To: <84439d81137d4f149012965b01ef4e84@TELMBXB02RM001.telecomitalia.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.125] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.593051E4.01DC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 458e0652f3f96f72f572ffbb856a55af Archived-At: Subject: Re: [ippm] R: WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jun 2017 17:42:00 -0000 I think this is ready for publication.=20 I have only one very minor editorial nit regarding document structure: Th= ere is a section 3.1.1 but no section 3.1.2. I think it is preferable to h= ave either at least two subsections, or none at all. I understand that 3.1= is a long section that may require breaking up. It seems that 3.1.1 could= actually be elevated one level to become 3.2. =20 Kind regards --- Alex -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Fioccola Giuseppe Sent: Thursday, June 01, 2017 1:19 AM To: Brian Trammell (IETF) ; IETF IPPM WG Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark Hi IPPMers, First, I want to thank IPPM chairs for starting WGLC phase. I think the document is stable and consolidated in terms of content and sco= pe. I support its publication (as co-author), also because there are related us= e cases, already presented within IETF, that need a reference document. Best Regards, Giuseppe -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Brian Trammell (IETF) Inviato: marted=EC 30 maggio 2017 17:53 A: IETF IPPM WG Oggetto: [ippm] WGLC on draft-ietf-ippm-alt-mark Greetings, IPPM, As discussed in Chicago, this message begins a Working Group Last Call on d= raft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday 20 June= 2017. Please reply to ippm@ietf.org indicating whether you believe this do= cument is ready for publication, and if not, why not. Many thanks, best regards, Brian (as IPPM co-chair) Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.=20 This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.=20 Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Fri Jun 2 10:11:56 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7218F127180 for ; Fri, 2 Jun 2017 10:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ax_wjV02q-Yc for ; Fri, 2 Jun 2017 10:11:52 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A262D1205F0 for ; Fri, 2 Jun 2017 10:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6153; q=dns/txt; s=iport; t=1496423512; x=1497633112; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=D8WHRe1/nHgOZeF66lDqJGnWKYIuvUXj2rcwNpDDphU=; b=M9sqOUzKDyFegx7aHZsIB3KptGPzbY5qnyfinNEQmnX9SY0DnQZHkjma K4ZINmUkAWjdbIum8lVgSCbkX9sTHJokvsu3f6zpCzklzXSkAE9lOJkmT f49VpN9BkCEM8ICAfTaaPEJ4KpMEmytn2+KcaWhV6qb57Fn06Lq8qGcdI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAQDVmzFZ/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1digQ0Hn3+VfIIPIQuCQoM2AoJ8QBcBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQMBATg0FwQCAQgRBAEBHwkHJwsUCQgCBAESCIoiELFbiw8BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYZhgWCDH4pcBZ4vAZMhgg+FPINthkuUWwEgATaBCnQVRoU?= =?us-ascii?q?GHIFjdohmgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.39,286,1493683200"; d="scan'208";a="431991828" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2017 17:11:51 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v52HBpKk020914 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 2 Jun 2017 17:11:51 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Jun 2017 12:11:50 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Fri, 2 Jun 2017 12:11:50 -0500 From: "Frank Brockners (fbrockne)" To: "Joe Clarke (jclarke)" , "ippm@ietf.org" Thread-Topic: [ippm] Review of draft-brockners-inband-oam-data-05 Thread-Index: AQHS2lbuVT34jO4PHUOXlTiiEZRqdKIRzGfg Date: Fri, 2 Jun 2017 17:11:50 +0000 Message-ID: <5585f9701093446aa250c91edc083619@XCH-RCD-008.cisco.com> References: <46e942a8-5890-8244-eba2-7ba104e2e601@cisco.com> In-Reply-To: <46e942a8-5890-8244-eba2-7ba104e2e601@cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.117.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Review of draft-brockners-inband-oam-data-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 02 Jun 2017 17:11:54 -0000 Hi Joe, thanks a lot for the detailed review. We'll address your comments in the ne= xt revision. Please find a couple of notes and responses inline... -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Joe Clarke (jclarke) Sent: Mittwoch, 31. Mai 2017 23:43 To: ippm@ietf.org Subject: [ippm] Review of draft-brockners-inband-oam-data-05 Hello, IPPM WG. I'm not an active IPPM WG participant, so while Brian rece= ntly called for adoption of this document, I will defer a comment there. I did, however, read the document, and I have some comments to the WG and a= uthors for consideration. One overall comment is that while "IOAM" is defined in the terminology sect= ion, it is not often used. Instead, the full "in-situ OAM" spelling is pre= ferred. To me, this gets a bit tiresome to read. You have defined the abb= reviation, and you should use it. =3D=3D=3D Section 4: I think it should be noted that nodes can be both in-situ encap/decap and t= ransit nodes. That is, a node that adds the container could also write to = it. ...FB: Good point. We'll add this. =3D=3D=3D Section 4.1: In Section 4 you state that every node need not be an IOAM transit node. But here in 4.1 you state that for the tracing option all nodes should be = transit/encap/decap nodes. While it doesn't say all nodes MUST be IOAM-awa= re, I think it would be beneficial if you stated (at least for operation pu= rposes) what one would expect from a domain that contains non-IOAM-aware no= des. ...FB: Again, a good point which will address in the next revision. =3D=3D=3D Since an IOAM deployment MAY choose to support either the software or hardw= are optimized tracing options, how would one know what is supported across = all nodes? It seems like one would need to encapsulate both if there is no= a priori way to learn about this. ...FB: With IOAM being a domain specific feature, the operator will know wh= ich trace option would be used, or whether both would be used in parallel. = If both would be used in parallel, because a mix of HW and SW forwarders is= used, the encap node would put both in.=20 =3D=3D=3D Your text discussing IOAM tracing options states: o Identification of the interface that a packet was received on. o Identification of the interface that a packet was sent out on. Later on you use the terms "ingress" and "egress". I think it would be goo= d to use them here as well. ...FB: Agreed. =3D=3D=3D Section 4.1.1 You refer to Section 4.1.4 as describing the format of the IOAM data types,= but this is really in 4.1.3, with 4.1.4 being examples of the data types (= same in 4.1.2). ...FB: Agreed. =3D=3D=3D You only define two bits for an 8-bit Flags field. What is expected of the= other six bits? ...FB: Those are reserved for future use. We can define them as MSB for now= . =3D=3D=3D Section 4.1.2 Seems like a missed copy-paste from Section 4.1.1. You describe Bit 1 as: Bit 1 When set indicates presence of ingress_if_id and egress_if_id in the node data. And Bit 9 as: Bit 9 When set indicates presence of ingress_if_id and egress_if_id wide in the node data. I think you should keep what you have in Section 4.1.1: Bit 1 When set indicates presence of ingress_if_id and egress_if_id (short format) in the node data. Bit 9 When set indicates presence of ingress_if_id and egress_if_id in wide format in the node data. ...FB: Good catch. Thanks! =3D=3D=3D With respect to Maximum Length, you say a simple comparison between "Opt Da= ta Len" and "Max Length" should be enough to decide if data can be added. = I'm not sure. In your description in Section 4.1 you state that the option= header will have fields for "number of fields recorded" and "maximum numbe= r". I don't see how that jibes with Section 4.1.2. ...FB: Again a good catch. What we say in 4.1 ("The number of node data fie= lds recorded and maximum number of node data that can be recorded are writt= en into the option header.") indeed needs to be adjusted, given that we onl= y carry the maximum length (per 4.1.2). =3D=3D=3D Section 4.1.3 You don't have a block figure for "app_data". Seems odd considering you do= for all other options. I'm also not clear on what this might be. You don't really describe it (same thing for wide app data). ...FB: "app_data" is a free form bit-field, which can be interpreted in a d= omain-specific way. We'll add some verbiage along with an example in the ne= xt rev. =3D=3D=3D Your wide ingress and egress interfaces use an overall 8-byte field, but yo= ur "empty" indicator is still 0xFFFFFFFF. I think this should either be 0x= FFFFFFFFFFFFFFFF or you need to state that EACH 4-byte field needs to be al= l-Fs. ...FB: Good catch... there were quite a few of those in the -04 version, an= d it seems that I did not catch all of those in the -05 version. =3D=3D=3D Section 4.2 You use POT, but you haven't added this to your terminology section above. = It's clear to me what it means, but I think it's worth standardizing all t= erminology. ...FB: We'll add POT to the list of abbreviations and provide for a short e= xplanation.=20 =3D=3D=3D Section 4.3 Same as above for "E2E." ...FB: We'll add E2E to the list of abbreviation. =3D=3D=3D Section 5 Above you stated that an IOAM transit node _could_ process IOAM data. I th= ink this is useful. I think it's worth stating in Section 5 that each IOAM= -aware node could choose to export IOAM data. It need not be at the edge. ...FB: Agreed that the option to export IOAM data at any node - not just at= the edges of a domain, could be useful. We'll note that this is an option = in the next rev. I think that's it for now. Thanks again for the detailed review! Frank Joe _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Fri Jun 2 11:15:04 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1973F12946A for ; Fri, 2 Jun 2017 11:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.624 X-Spam-Level: X-Spam-Status: No, score=-12.624 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 jH0xb0Cn-2gX for ; Fri, 2 Jun 2017 11:15:01 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88881294EC for ; Fri, 2 Jun 2017 11:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1320; q=dns/txt; s=iport; t=1496427300; x=1497636900; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=+00j9ce8s81uJUs2hvMtEqnc6sDLMfuoPET15GrUzM4=; b=G3TPpgpO24u6a8fPNeiu+8BJTQ/5ql6s3sAQZ06eTRoOKtx8Zc8K+7LT 6ue/yYUx8LBpyHxU8+VaJ97eeb8QR5O20Vcr3GcDACZUxTxPg4wJ1h+2S N4x0xypW4BwcxwSnBt8rPhYOQitKbF7dVR2RxST1WrK8tRu9FBHsFNFX/ U=; X-IronPort-AV: E=Sophos;i="5.39,286,1493683200"; d="scan'208";a="255932305" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jun 2017 18:14:59 +0000 Received: from [10.150.72.173] (dhcp-10-150-72-173.cisco.com [10.150.72.173]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v52IEx6d023656; Fri, 2 Jun 2017 18:14:59 GMT To: "Frank Brockners (fbrockne)" , "ippm@ietf.org" References: <46e942a8-5890-8244-eba2-7ba104e2e601@cisco.com> <5585f9701093446aa250c91edc083619@XCH-RCD-008.cisco.com> From: Joe Clarke Organization: Cisco Message-ID: <2e0ed66e-97ff-ea0f-a39e-2eab19711bcd@cisco.com> Date: Fri, 2 Jun 2017 14:14:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5585f9701093446aa250c91edc083619@XCH-RCD-008.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ippm] Review of draft-brockners-inband-oam-data-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 02 Jun 2017 18:15:02 -0000 On 6/2/17 13:11, Frank Brockners (fbrockne) wrote: > Hi Joe, > > thanks a lot for the detailed review. We'll address your comments in the next revision. Please find a couple of notes and responses inline... No problem. I definitely support the work. > Since an IOAM deployment MAY choose to support either the software or hardware optimized tracing options, how would one know what is supported across all nodes? It seems like one would need to encapsulate both if there is no a priori way to learn about this. > > ...FB: With IOAM being a domain specific feature, the operator will know which trace option would be used, or whether both would be used in parallel. If both would be used in parallel, because a mix of HW and SW forwarders is used, the encap node would put both in. Okay. Perhaps some text can be added to make this more explicit? > You only define two bits for an 8-bit Flags field. What is expected of the other six bits? > > ...FB: Those are reserved for future use. We can define them as MSB for now. What I've learned from reading other reviews is that making it explicit that these bits are reserved and must be ignored is highly recommended in I-Ds. That's why I raised the point. > > Thanks again for the detailed review! Frank Again, my pleasure. Joe From nobody Sun Jun 4 05:37:14 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A7A1294DF for ; Sun, 4 Jun 2017 05:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.623 X-Spam-Level: X-Spam-Status: No, score=-12.623 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 lRwCPJM-JZeM for ; Sun, 4 Jun 2017 05:37:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1BBE1294D4 for ; Sun, 4 Jun 2017 05:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1726; q=dns/txt; s=iport; t=1496579831; x=1497789431; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KFrstuMXg211NaKJFsw5Z/JB4DnJ3/CdukZWtuGI0R4=; b=OJhtYa7h767QDPsNGrk6uzCK9gv3+cBwg4f1Udyy7J/Csi2PiIHiYBdF 5O2uAaulhvbOUYgkFX7uVN4J9f0aCuqkT1tH90lU9GDoIX5NGtm+lWJYw GXLn/Oj3b8yKfSysmP7WdByq3ewhRACTlYiBVEoFCJ6QGU1DXgek5H7jR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AAAu/jNZ/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0Hg2yKGZFcIpV9ghAhC4V4AhqCYj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQECAQEBGwYROhsCAQgYAgImAgICJQsVEAIEARKKIggQrVyCJosGAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWBC4c2KwuCaYRqgxIwgjEFnjMBhyGMCwuRcZR?= =?us-ascii?q?eAR84P0t0FUYSAYZzdokVgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.39,296,1493683200"; d="scan'208";a="257060819" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jun 2017 12:37:10 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v54CbAXv028258 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 4 Jun 2017 12:37:10 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 4 Jun 2017 07:37:10 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Sun, 4 Jun 2017 07:37:10 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "Brian Trammell (IETF)" , "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for draft-brockners-inband-oam-data Thread-Index: AQHS2R1C09H6Sg/DMUS0qR/CgQ4+46IUuFKA Date: Sun, 4 Jun 2017 12:37:09 +0000 Message-ID: References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> In-Reply-To: <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.216.211] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 12:37:13 -0000 SGksDQogDQooMSkgd2hldGhlciB5b3Ugc3VwcG9ydCBhZGRpdGlvbiBvZiB0aGUgZm9sbG93aW5n IG1pbGVzdG9uZSB0byB0aGUgSVBQTSBjaGFydGVyOg0KDQpZZXMvU3VwcG9ydA0KICAgICAgICAN CigyKSB3aGV0aGVyIHlvdSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBkcmFmdC1icm9ja25lcnMt aW5iYW5kLW9hbS1kYXRhLTA1IGFzIHRoZSBiYXNpcyBkb2N1bWVudCBmb3IgdGhpcyBtaWxlc3Rv bmUNClllcy9TdXBwb3J0Lg0KICAgIA0KICAgICgzKSB3aGV0aGVyIHlvdSBjb21taXQgdG8gcmV2 aWV3aW5nIHRoZSBkb2N1bWVudCBpZiBhZG9wdGVkDQogICAgWWVzLg0KICAgIA0KVGhhbmtzLA0K TmFnZW5kcmEgICAgDQogICAgDQogICAgPiBPbiAyOSBNYXkgMjAxNywgYXQgMTc6MjYsIEZyYW5r IEJyb2NrbmVycyAoZmJyb2NrbmUpIDxmYnJvY2tuZUBjaXNjby5jb20+IHdyb3RlOg0KICAgID4g DQogICAgPiBEZWFyIElQUE0gV0csDQogICAgPiANCiAgICA+IHdl4oCZdmUganVzdCBwb3N0ZWQg YW4gdXBkYXRlZCB2ZXJzaW9uIG9mIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGE6IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRh LTA1IHdoaWNoIGlzIHRvIGFkZHJlc3MgdGhlIHJlY2VudCBjb21tZW50cyBvbiB0aGUgbWFpbGlu ZyBsaXN0LiBUaGUgbWFpbiBjaGFuZ2UgaXMgdGhlIHZlcmJpYWdlIGFyb3VuZCB0aGUgbmVlZCB0 byBlbnN1cmUgdGhhdCBJT0FNIGRhdGEgaXMga2VwdCB3aXRoaW4gdGhlIElPQU0gZG9tYWluLiBJ biBhZGRpdGlvbiwgc2V2ZXJhbCBlZGl0b3JpYWwgbml0cyBoYXZlIGJlZW4gY2xlYW5lZCB1cC4N CiAgICA+IA0KICAgID4gV2UgYXBwcmVjaWF0ZSB5b3VyIHRob3VnaHRzIGFuZCBjb21tZW50cy4N CiAgICA+IA0KICAgID4gUmVnYXJkcywgRnJhbmsNCiAgICA+IA0KICAgID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IGlwcG0gbWFpbGluZyBs aXN0DQogICAgPiBpcHBtQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwcG0NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICAgIGlwcG0gbWFpbGluZyBsaXN0DQogICAgaXBwbUBpZXRm Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0KICAg IA0KDQo= From nobody Sun Jun 4 18:24:49 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B1A126BF3 for ; Sun, 4 Jun 2017 18:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 QF6SWBBodedx for ; Sun, 4 Jun 2017 18:24:46 -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 3365E124234 for ; Sun, 4 Jun 2017 18:24:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOK42685; Mon, 05 Jun 2017 01:24:42 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 5 Jun 2017 02:24:41 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.160]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 5 Jun 2017 09:24:34 +0800 From: Qin Wu To: "Brian Trammell (IETF)" , IETF IPPM WG Thread-Topic: [ippm] WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2VzuNSoXtl9Lj0WLtmtkPpceE6IVfXyw Date: Mon, 5 Jun 2017 01:24:34 +0000 Message-ID: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> In-Reply-To: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5934B2DB.0006, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1059455288d20deb52f4d16bb8c0980b Archived-At: Subject: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jun 2017 01:24:48 -0000 SSBoYXZlIHJlLXJlYWQgdGhpcyBkb2N1bWVudCBhbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3Ig cHVibGljYXRpb24uDQpIZXJlIGFyZSBhIGZldyBtaW5vciBjb21tZW50cyBhcyBmb2xsb3dzOg0K MS4gSSBmZWVsIGRpc2Nvbm5lY3RlZCB3aGVuIEkgcmVhZCB0aGUgbGFzdCBzZW50ZW5jZSBvZiBm bG93IGJhc2VkIHN0cmF0ZWd5IHNlY3Rpb246DQoiDQogICAgICBBbm90aGVyIGFwcGxpY2F0aW9u DQogICAgICBpcyBvbiBNb2JpbGUgQmFja2hhdWxpbmcsIGltcGxlbWVudGVkIHdpdGggYSBWUE4g TVBMUyBpbiBUZWxlY29tDQogICAgICBJdGFsaWEncyBuZXR3b3JrOyBpbiB0aGlzIGNhc2UgdGhl IHByb2JsZW0gd2l0aCB1bmljYXN0IHRyYWZmaWMgaXMNCiAgICAgIG92ZXJjb21lIGJ5IG1vbml0 b3JpbmcganVzdCB0aGUgdHdvIFByb3ZpZGVyIEVkZ2Ugbm9kZXMgb2YgdGhlIFZQTg0KICAgICAg TVBMUy4NCiINCkhvdyB0aGlzIGlzIHJlbGF0ZWQgdG8gZmxvdyBiYXNlZCBjYXNlPyBIb3cgZG8g eW91IGFkZHJlc3MgbG9hZC1iYWxhbmNpbmcgaXNzdWUgaW4gTW9iaWxlIGJhY2toYXVsaW5nIGNh c2UgYnkgbW9uaXRvcmluZyB0d28gUEVzIG5vZGVzLg0KSSBzdXBwb3NlIHRoZXJlIGFyZSBtdWx0 aXBsZSBob3BzIGJldHdlZW4gdHdvIFBFIG5vZGVzLCBJIGFzc3VtZSBsYWJlbCBlbnRyb3B5IG1h eSBiZSB1c2VkIHRvIGFkZHJlc3MgbG9hZCBiYWxhbmNpbmcgaXNzdWUuDQoNCjIuIEFzIGRlc2Ny aWJlZCBpbiB0aGlzIGRyYWZ0LCBUcmFmZmljIGNvbG9yaW5nIGNhbiBiZSBpbXBsZW1lbnRlZCBi eSBzZXR0aW5nIGEgc3BlY2lmaWMgYml0IGluIHRoZQ0KIHBhY2tldCBoZWFkZXIgYW5kIGNoYW5n aW5nIHRoZSB2YWx1ZSBvZiB0aGF0IGJpdCBwZXJpb2RpY2FsbHkuIEJ1dCBpdCBsb29rcyBpbiB0 aGlzIGRyYWZ0LCB0cmFmZmljIGNvbG9yaW5nIGlzIG9ubHkgc3VwcG9ydGVkIGJ5IHNldHRpbmcg YSBzcGVjaWZpYyBiaXQgb2YgUW9TIHJlbGF0ZWQgZmllbGQgc3VjaCBhcyBEU0NQIGZpZWxkLg0K IElzIHRoaXMgcmVhbCBpbnRlbnRpb24gb3IgeW91IGNhbiBzdXBwb3J0IG90aGVyIHRyYWZmaWMg Y29sb3IgYXMgd2VsbD8NCjMuQXMgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQsIHR3byBlbmNvZGlu Z3Mgb2YgdGhlIERTQ1AgZmllbGQgY2FuIGJlIHVzZWQgdG8gY29sb3IgdGhlIHBhY2tldHM/IFdo YXQgZG8geW91IG1lYW4gYnkgdHdvIGVuY29kaW5nLCBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNv cnJlY3QsIHlvdSB1c2Ugb25lIGJpdCAoYml0IDEpIG9mIHRoZSBEU0NQIGZpbGVkIHRvIGNvbG9y IHRoZSBwYWNrZXRzLCBvbmUgYml0IChiaXQgMCkgdG8gaW5kaWNhdGUgZmxvdyB1bmRlciB0cmFm ZmljIG1vbml0b3JpbmcuDQogV2hlbiBiaXQgMSBpcyBzZXQgdG8gMCwgaXQgY29ycmVzcG9uZHMg dG8gY29sb3IgQSwgd2hlbiBiaXQxIGlzIHNldCB0byAxLCBpdCBjb3JyZXNwb25kcyB0byBjb2xv ciBCLCBJcyBiaXQxIHNldCB0byAwIGNvcnJlc3BvbmRpbmcgdG8gb25lIGVuY29kaW5nIHdoaWxl IGJpdDEgc2V0IHRvIDEgY29ycmVzcG9uZGluZyB0byB0aGUgb3RoZXIgZW5jb2Rpbmc/DQo0LiBT ZWN0aW9uIDUuMS4yIHRoZSAybmQgcGFyYWdyYXBoDQpzL2EgY291cGxlIG9kIGNvdW50ZXJzL2Eg Y291cGxlIG9mIGNvdW50ZXJzDQoNCi1RaW4NCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBp cHBtIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEJyaWFuIFRyYW1tZWxsIChJ RVRGKQ0Kt6LLzcqxvOQ6IDIwMTfE6jXUwjMwyNUgMjM6NTMNCsrVvP7IyzogSUVURiBJUFBNIFdH DQrW98ziOiBbaXBwbV0gV0dMQyBvbiBkcmFmdC1pZXRmLWlwcG0tYWx0LW1hcmsNCg0KR3JlZXRp bmdzLCBJUFBNLA0KDQpBcyBkaXNjdXNzZWQgaW4gQ2hpY2FnbywgdGhpcyBtZXNzYWdlIGJlZ2lu cyBhIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtaXBwbS1hbHQtbWFyaywg dG8gIHRvIHJ1biB1bnRpbCBFT0IgQ0VTVCAoVVRDICsyKSBUdWVzZGF5IDIwIEp1bmUgMjAxNy4g UGxlYXNlIHJlcGx5IHRvIGlwcG1AaWV0Zi5vcmcgaW5kaWNhdGluZyB3aGV0aGVyIHlvdSBiZWxp ZXZlIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBhbmQgaWYgbm90LCB3 aHkgbm90Lg0KDQpNYW55IHRoYW5rcywgYmVzdCByZWdhcmRzLA0KDQpCcmlhbiAoYXMgSVBQTSBj by1jaGFpcikNCg== From nobody Mon Jun 5 08:27:00 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58AE1294A2 for ; Mon, 5 Jun 2017 08:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 W_TmY7OQXs2a for ; Mon, 5 Jun 2017 08:26:55 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0138.outbound.protection.outlook.com [104.47.36.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D810129496 for ; Mon, 5 Jun 2017 08:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jE+7H9qYLD4KkWQVgSz9/m/IWozKh6vuUVl2VoFktzE=; b=Ebo4JZDh7vKPXscfbnQOY0F+0xtVJm3YecI/EOXBP7mZu3YoJFGEzCKzdm94+Mbb2h+Ee1yWcZZJ711dB+13WfxfKL/4OwVUiwpWTrn+7tciPtY5soUD7jYpwYf5r3g3Mh3eJ03EGtj1aH9Ol+3ZbRyfoLjyR8xPlPXzcpfIz0U= Received: from BY1PR0501MB1352.namprd05.prod.outlook.com (10.160.200.24) by BY1PR0501MB1303.namprd05.prod.outlook.com (10.160.200.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.6; Mon, 5 Jun 2017 15:26:54 +0000 Received: from BY1PR0501MB1352.namprd05.prod.outlook.com ([10.160.200.24]) by BY1PR0501MB1352.namprd05.prod.outlook.com ([10.160.200.24]) with mapi id 15.01.1157.010; Mon, 5 Jun 2017 15:26:53 +0000 From: Sudhin Jacob To: "Brian Trammell (IETF)" , IETF IPPM WG Thread-Topic: [ippm] R: WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2q+/AsGEhTl3zUiWdww54WdpN6IQR1UAgAYjB2A= Date: Mon, 5 Jun 2017 15:26:53 +0000 Message-ID: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> <84439d81137d4f149012965b01ef4e84@TELMBXB02RM001.telecomitalia.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0DFB2D55@SJCEML701-CHM.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DFB2D55@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: trammell.ch; dkim=none (message not signed) header.d=none;trammell.ch; dmarc=none action=none header.from=juniper.net; x-originating-ip: [116.197.184.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1303; 7:J7SJTY06PEUJLRMpCWZtHjZk+PaXughalKHixduIw2Qi5GKcnBHCiR0MI8+DoTRHbFuVYdzr32kZWzWdb+xrPsndn6SrgbpkWysZ7XN667TUG/aaaJM2jS9F/oV2q3aS1rAt8+RgIhZBXhCXyaWDB/F4WfgCPKXOqjLOs1/Cmx6+2JX9of7rmZi6mfoFkH7vI+w4RzShIEt70g49B3RY78fpE32cTuO8gyORD64cLQq4rR1DP4+hZ72ke7naLLFRlN4bE28Ie8HEOJK2Co99+VQhrNtbtzBDmfxLQjeuQL4Lxh1BXSBYTcLl7ih3i5ONQU9tvEV3aCS7A3e5u0lZ0Q== x-ms-traffictypediagnostic: BY1PR0501MB1303: x-ms-office365-filtering-correlation-id: 38e23695-c118-4144-25c6-08d4ac274ba5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BY1PR0501MB1303; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(43073073696351); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0501MB1303; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0501MB1303; x-forefront-prvs: 0329B15C8A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39840400002)(39860400002)(39850400002)(39400400002)(39450400003)(13464003)(53754006)(66654002)(377454003)(189998001)(229853002)(3660700001)(53546009)(3846002)(6116002)(102836003)(3280700002)(5890100001)(2906002)(4326008)(6306002)(6506006)(55016002)(7696004)(77096006)(8936002)(53936002)(99286003)(54906002)(9686003)(8676002)(966005)(25786009)(6436002)(2950100002)(81166006)(54356999)(76176999)(66066001)(38730400002)(478600001)(14454004)(122556002)(50986999)(7736002)(305945005)(230783001)(86362001)(33656002)(5660300001)(74316002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1303; H:BY1PR0501MB1352.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2017 15:26:53.8430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1303 Archived-At: Subject: Re: [ippm] R: WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jun 2017 15:26:58 -0000 Hi All, I support this draft. I think it is good for publication. Regards, Sudhin -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Alexander Clemm Sent: Thursday, June 1, 2017 11:12 PM To: Fioccola Giuseppe ; Brian Trammell = (IETF) ; IETF IPPM WG Subject: Re: [ippm] R: WGLC on draft-ietf-ippm-alt-mark I think this is ready for publication.=20 I have only one very minor editorial nit regarding document structure: Th= ere is a section 3.1.1 but no section 3.1.2. I think it is preferable to h= ave either at least two subsections, or none at all. I understand that 3.1= is a long section that may require breaking up. It seems that 3.1.1 could= actually be elevated one level to become 3.2. =20 Kind regards --- Alex -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Fioccola Giuseppe Sent: Thursday, June 01, 2017 1:19 AM To: Brian Trammell (IETF) ; IETF IPPM WG Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark Hi IPPMers, First, I want to thank IPPM chairs for starting WGLC phase. I think the document is stable and consolidated in terms of content and sco= pe. I support its publication (as co-author), also because there are related us= e cases, already presented within IETF, that need a reference document. Best Regards, Giuseppe -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Brian Trammell (IETF) Inviato: marted=EC 30 maggio 2017 17:53 A: IETF IPPM WG Oggetto: [ippm] WGLC on draft-ietf-ippm-alt-mark Greetings, IPPM, As discussed in Chicago, this message begins a Working Group Last Call on d= raft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday 20 June= 2017. Please reply to ippm@ietf.org indicating whether you believe this do= cument is ready for publication, and if not, why not. Many thanks, best regards, Brian (as IPPM co-chair) Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.=20 This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.=20 Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. _______________________________________________ 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 From nobody Mon Jun 5 15:33:19 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28336128D44 for ; Mon, 5 Jun 2017 15:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DCMChIIkFQ54 for ; Mon, 5 Jun 2017 15:33:15 -0700 (PDT) Received: from aws.hosed.org (aws.hosed.org [50.16.104.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE580126557 for ; Mon, 5 Jun 2017 15:33:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by aws.hosed.org (Postfix) with ESMTP id 2676C803E3; Mon, 5 Jun 2017 18:33:14 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at aws.hosed.org Received: from aws.hosed.org ([127.0.0.1]) by localhost (aws.hosed.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14DS0NFg--41; Mon, 5 Jun 2017 18:33:14 -0400 (EDT) Received: from divinaair.netscout.com (50-195-106-33-static.hfc.comcastbusiness.net [50.195.106.33]) by aws.hosed.org (Postfix) with ESMTPSA id E3DD3803E2; Mon, 5 Jun 2017 18:33:13 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sarah B In-Reply-To: <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> Date: Mon, 5 Jun 2017 15:33:12 -0700 Cc: "ippm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> To: "Brian Trammell (IETF)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jun 2017 22:33:17 -0000 Hello, Although I do have reservations about this draft, I do think it = deserves the chance to be worked on by the group and come to the = penultimate consensus (or not) to move it forward to publication. That = said, I do not believe the current charter allows this draft to come in; = the charter is pretty clear that network OAM is out of scope, and so a = charter change has to happen. If we recharter, are we planning to do so = to accommodate this one draft, or future OAM work as well? Given Brian's Q's below: 1. I support the addition of the milestone. I can't decide on = another place to take this work; IPPM seems most apropos. 2. I support the adoption of draft-brockners-etc as the basis = document for the milestone 3. I think there are minutes somewhere that signed me up for = this reviewing already :) Thanks Sarah > On May 30, 2017, at 1:17 AM, Brian Trammell (IETF) = wrote: >=20 > Greetings, IPPM, >=20 > At our Chicago meeting, we decided we needed a single, cleaned-up = document containing appropriate scoping and rationale in order to make a = decision as to whether we'd like to adopt IOAM within IPPM. This = revision of draft-brockners-inband-oam-data is that document. >=20 > This message, therefore, starts a call for adoption on = draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday = 20 June 2017. Please reply to ippm@ietf.org indicating: >=20 > (1) whether you support addition of the following milestone to the = IPPM charter: >=20 > date TBD: Submit an Experimental draft on inband OAM based measurement = methodologies to the IESG >=20 > (2) whether you support the adoption of = draft-brockners-inband-oam-data-05 as the basis document for this = milestone >=20 > (3) whether you commit to reviewing the document if adopted >=20 >=20 > We are aware that there is an open question as to whether we can adopt = draft-brockners-inband-oam-data under our current charter; we'd like to = see if there is IPPM WG consensus on adoption before discussing a = recharter, hopefully before Prague, though we can take face-to-face time = in Prague for this if necessary. Our intention, as chairs, is to make = the minimal necessary change to the charter should there be consensus = for adoption. However, if you have particular opinions as to how this = should be done, please also address these in your message. >=20 > Many thanks, best regards, >=20 > Brian (as IPPM co-chair) >=20 >=20 >=20 >> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) = wrote: >>=20 >> Dear IPPM WG, >>=20 >> we=E2=80=99ve just posted an updated version of = draft-brockners-inband-oam-data: = https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is = to address the recent comments on the mailing list. The main change is = the verbiage around the need to ensure that IOAM data is kept within the = IOAM domain. In addition, several editorial nits have been cleaned up. >>=20 >> We appreciate your thoughts and comments. >>=20 >> Regards, Frank >>=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 Mon Jun 5 19:03:05 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649BF12EB80 for ; Mon, 5 Jun 2017 19:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Qlz3E2Ujphxo for ; Mon, 5 Jun 2017 19:03:01 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F90712EB77 for ; Mon, 5 Jun 2017 19:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4734; q=dns/txt; s=iport; t=1496714581; x=1497924181; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=w5Bh8zp60/5XCaxU6pJQbdWtNHOqlhL0CWeE4Mn5wNY=; b=keTi9IA1Hm1qZo6YZNTiONEeDLpiIWXIK8cuGWPc9PDnBE870QwfI82l jA4j//YxfEXKX5j6h9ZXdDwhQZK+QFhs01xJmW3lWMH0+jesO7uHvZWGs VYnLIMVFMkNhbii8fSzQw4zMi3+IlIFqHodLhcmfsiAMLCe83pdRIF/Fk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAAADDDZZ/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0Hg2yKGZIDcpULghAhC4V4AhqCbj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQECAQEBGwYROgsFCwIBCBgCAiYCAgIlCxQBEAIEDgUUig4IEK0IgiaMB?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFVoFgK4JANIRqgxIwgjEFnjMBhyG?= =?us-ascii?q?DN4hUggaFPoo4lF4BHziBCnQVRhIBhHMcgWR2iB2BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,304,1493683200"; d="scan'208";a="436244062" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2017 02:03:00 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v5622xDm000501 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Jun 2017 02:03:00 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 5 Jun 2017 22:02:59 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 5 Jun 2017 22:02:58 -0400 From: "Carlos Pignataro (cpignata)" To: "Brian Trammell (IETF)" CC: "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for draft-brockners-inband-oam-data Thread-Index: AQHS2R1BVgmhfTAJ5k6S7ptX5bY4baIXYt0A Date: Tue, 6 Jun 2017 02:02:58 +0000 Message-ID: References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> In-Reply-To: <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.131] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 02:03:03 -0000 SGksIEJyaWFuLA0KDQpUaGFuayB5b3UgZm9yIGRyaXZpbmcgdGhpcyBwb2xsLg0KDQpJIGNsZWFy bHkgc3VwcG9ydCB0aGlzIHdvcmsgYW5kIGJlbGlldmUgaXQgd2lsbCBiZSBJRVRGLWN5Y2xlcyB2 ZXJ5IHdlbGwgaW52ZXN0ZWQgdG8gYWR2YW5jZSBhbmQgcHVibGlzaCB0aGlzIHdvcmsuDQoNClRv IHRoYXQgZW5kLCBhIGNvdXBsZSBvZiBjb21tZW50czoNCg0KKDEpIEkgc3VwcG9ydCB0aGUgYWRk aXRpb24gb2YgYSBtaWxlc3RvbmUgdG8gSVBQTSwgdG8gaGF0IHRoaXMgd29yayBmcm9tLiBUaGF0 IG1heSByZXF1aXJlIGEgb25lLWxpbmVyIOKAnHJlY2hhcnRlcuKAnSwgYnV0IGxldOKAmXMgbm90 IGJsb2F0IHRoZSBwcm9jZXNzLXdhcmUuDQoNCkhvd2V2ZXIsIGEgY291cGxlIG9mIGNvbW1lbnRz Og0KDQpMZXTigJlzIGNoYW5nZSDigJxpbmJhbmQgT0FNIGJhc2Vk4oCdIGZvciDigJxpbi1zaXR1 4oCdIG9yIOKAnGh5YnJpZCBtb2RlbCBzb21ldGhpbmfigJ0sIG9yIGFueXRoaW5nIHRoYXQgZG9l cyBub3QgY2F1c2VzIHBvdGVudGlhbCBjb25mdXNpb24uDQoNCldlIGNvdWxkIGdlbmVyYWxpemUg 4oCcIG1lYXN1cmVtZW50IG1ldGhvZG9sb2dpZXPigJ0gYXMg4oCcIG1ldGhvZG9sb2dpZXMgaW5j bHVkaW5nIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW504oCdLg0KDQpJIGtub3cgdGhlIGRyYWZ0IGlz IG5vdyBsYWJlbGVkIGFzIEV4cGVyaW1lbnRhbCwgYnV0IGZyYW5rbHkgdGhpcyBpcyBubyDigJxy ZXNlYXJjaCBwcm9qZWN04oCdLCBhbmQgdGhlcmXigJlzIG5vIGV4cGVyaW1lbnQgcGVyLXNlLiBD b25zZXF1ZW50bHksIEnigJlkIHN1cHBvcnQgc3RhbmRhcmRzIHRyYWNrLg0KDQooMikgRGVmaW5p dGVseS4gZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YSBjb250aW51ZXMgdG8gaW5jb3Jw b3JhdGUgY29tbXVuaXR5IGZlZWRiYWNrIGFuZCByZXZpZXcgYW5kIGlzIGEgc29saWQgc3RhcnRp bmcgcG9pbnQgZm9yIHNhaWQgbWlsZXN0b25lLg0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoN Cg0KPiBPbiBNYXkgMzAsIDIwMTcsIGF0IDQ6MTcgQU0sIEJyaWFuIFRyYW1tZWxsIChJRVRGKSA8 aWV0ZkB0cmFtbWVsbC5jaD4gd3JvdGU6DQo+IA0KPiBHcmVldGluZ3MsIElQUE0sDQo+IA0KPiBB dCBvdXIgQ2hpY2FnbyBtZWV0aW5nLCB3ZSBkZWNpZGVkIHdlIG5lZWRlZCBhIHNpbmdsZSwgY2xl YW5lZC11cCBkb2N1bWVudCBjb250YWluaW5nIGFwcHJvcHJpYXRlIHNjb3BpbmcgYW5kIHJhdGlv bmFsZSBpbiBvcmRlciB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hldGhlciB3ZSdkIGxpa2Ug dG8gYWRvcHQgSU9BTSB3aXRoaW4gSVBQTS4gVGhpcyByZXZpc2lvbiBvZiBkcmFmdC1icm9ja25l cnMtaW5iYW5kLW9hbS1kYXRhIGlzIHRoYXQgZG9jdW1lbnQuDQo+IA0KPiBUaGlzIG1lc3NhZ2Us IHRoZXJlZm9yZSwgc3RhcnRzIGEgY2FsbCBmb3IgYWRvcHRpb24gb24gZHJhZnQtYnJvY2tuZXJz LWluYmFuZC1vYW0tZGF0YSwgdG8gcnVuIHVudGlsIEVPQiBDRVNUIChVVEMgKzIpIFR1ZXNkYXkg MjAgSnVuZSAyMDE3LiBQbGVhc2UgcmVwbHkgdG8gaXBwbUBpZXRmLm9yZyBpbmRpY2F0aW5nOg0K PiANCj4gKDEpIHdoZXRoZXIgeW91IHN1cHBvcnQgYWRkaXRpb24gb2YgdGhlIGZvbGxvd2luZyBt aWxlc3RvbmUgdG8gdGhlIElQUE0gY2hhcnRlcjoNCj4gDQo+IGRhdGUgVEJEOiBTdWJtaXQgYW4g RXhwZXJpbWVudGFsIGRyYWZ0IG9uIGluYmFuZCBPQU0gYmFzZWQgbWVhc3VyZW1lbnQgbWV0aG9k b2xvZ2llcyB0byB0aGUgSUVTRw0KPiANCj4gKDIpIHdoZXRoZXIgeW91IHN1cHBvcnQgdGhlIGFk b3B0aW9uIG9mIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEtMDUgYXMgdGhlIGJhc2lz IGRvY3VtZW50IGZvciB0aGlzIG1pbGVzdG9uZQ0KPiANCj4gKDMpIHdoZXRoZXIgeW91IGNvbW1p dCB0byByZXZpZXdpbmcgdGhlIGRvY3VtZW50IGlmIGFkb3B0ZWQNCj4gDQo+IA0KPiBXZSBhcmUg YXdhcmUgdGhhdCB0aGVyZSBpcyBhbiBvcGVuIHF1ZXN0aW9uIGFzIHRvIHdoZXRoZXIgd2UgY2Fu IGFkb3B0IGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEgdW5kZXIgb3VyIGN1cnJlbnQg Y2hhcnRlcjsgd2UnZCBsaWtlIHRvIHNlZSBpZiB0aGVyZSBpcyBJUFBNIFdHIGNvbnNlbnN1cyBv biBhZG9wdGlvbiBiZWZvcmUgZGlzY3Vzc2luZyBhIHJlY2hhcnRlciwgaG9wZWZ1bGx5IGJlZm9y ZSBQcmFndWUsIHRob3VnaCB3ZSBjYW4gdGFrZSBmYWNlLXRvLWZhY2UgdGltZSBpbiBQcmFndWUg Zm9yIHRoaXMgaWYgbmVjZXNzYXJ5LiBPdXIgaW50ZW50aW9uLCBhcyBjaGFpcnMsIGlzIHRvIG1h a2UgdGhlIG1pbmltYWwgbmVjZXNzYXJ5IGNoYW5nZSB0byB0aGUgY2hhcnRlciBzaG91bGQgdGhl cmUgYmUgY29uc2Vuc3VzIGZvciBhZG9wdGlvbi4gSG93ZXZlciwgaWYgeW91IGhhdmUgcGFydGlj dWxhciBvcGluaW9ucyBhcyB0byBob3cgdGhpcyBzaG91bGQgYmUgZG9uZSwgcGxlYXNlIGFsc28g YWRkcmVzcyB0aGVzZSBpbiB5b3VyIG1lc3NhZ2UuDQo+IA0KPiBNYW55IHRoYW5rcywgYmVzdCBy ZWdhcmRzLA0KPiANCj4gQnJpYW4gKGFzIElQUE0gY28tY2hhaXIpDQo+IA0KPiANCj4gDQo+PiBP biAyOSBNYXkgMjAxNywgYXQgMTc6MjYsIEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxmYnJv Y2tuZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiBEZWFyIElQUE0gV0csDQo+PiANCj4+IHdl 4oCZdmUganVzdCBwb3N0ZWQgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIGRyYWZ0LWJyb2NrbmVycy1p bmJhbmQtb2FtLWRhdGE6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icm9ja25l cnMtaW5iYW5kLW9hbS1kYXRhLTA1IHdoaWNoIGlzIHRvIGFkZHJlc3MgdGhlIHJlY2VudCBjb21t ZW50cyBvbiB0aGUgbWFpbGluZyBsaXN0LiBUaGUgbWFpbiBjaGFuZ2UgaXMgdGhlIHZlcmJpYWdl IGFyb3VuZCB0aGUgbmVlZCB0byBlbnN1cmUgdGhhdCBJT0FNIGRhdGEgaXMga2VwdCB3aXRoaW4g dGhlIElPQU0gZG9tYWluLiBJbiBhZGRpdGlvbiwgc2V2ZXJhbCBlZGl0b3JpYWwgbml0cyBoYXZl IGJlZW4gY2xlYW5lZCB1cC4NCj4+IA0KPj4gV2UgYXBwcmVjaWF0ZSB5b3VyIHRob3VnaHRzIGFu ZCBjb21tZW50cy4NCj4+IA0KPj4gUmVnYXJkcywgRnJhbmsNCj4+IA0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGlwcG0gbWFpbGluZyBsaXN0 DQo+PiBpcHBtQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwcG0NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IGlwcG0gbWFpbGluZyBsaXN0DQo+IGlwcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCg== From nobody Tue Jun 6 00:39:14 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D9512EBBD for ; Tue, 6 Jun 2017 00:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 3u5o9H5tg87f for ; Tue, 6 Jun 2017 00:39:10 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0108.outbound.protection.outlook.com [104.47.0.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F071294A1 for ; Tue, 6 Jun 2017 00:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PizeIeDd9lxRqpcUQ6IJCUoPgfqIdAi2Ffs8BwTLwG8=; b=IR5piHBoqmJhMLg85tqJsY+4Iba7+QHXSUzC0MhEX2iNiDwvI/l/HyNBTykP/8051YLznFt4O55v83hnYx21wZzf15OTI4amWdVPBrXzPRkJhCXIwwVLidtUJoC1qCiMMGGDN0ZI7r6eMEwH6Q7hna4G4astjLtikRsfF9xAEwo= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1364.eurprd07.prod.outlook.com (10.164.82.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.9; Tue, 6 Jun 2017 07:39:07 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::b1c5:669b:aac9:7733]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::b1c5:669b:aac9:7733%14]) with mapi id 15.01.1157.010; Tue, 6 Jun 2017 07:39:07 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: IETF IPPM WG Thread-Topic: [ippm] R: WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2v5lp70L/QP7hUGjF4ygUnXMJaIWalSAgAExKIA= Date: Tue, 6 Jun 2017 07:39:07 +0000 Message-ID: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> <84439d81137d4f149012965b01ef4e84@TELMBXB02RM001.telecomitalia.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0DFB2D55@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.25] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1364; 7:SaI2Qr4YBlLX+9dJ+6ylkXbGf9WqyMe2mLL/uQ7G4uSgW028TjHgv8mTpykuiqPQAetH5ZVwaxEfzJ6LlTHbTrjm+ZNZw+EoziHJuL+3snp44Wklj9HwGszZYffMQdpBzY7oPk3ZErT7gC+WwskS6n8ICETKVh08M12ob3xYCscqs8GYLoROgcBnbaAtiZj9688pB2fKL5LNm6OKIxGC/eaE8duWQ95DMSw5Z0q3eYOwZ4uDFwoLG7qENHoJiFboFxT3YoHTL85udTIpQBXWNxsdju8bM5z3Mg3jyAQUfYWMFs2g9M3+XzPEZ6DLEutSCC6q5ILXItK3TpTp9Ct19w== x-ms-traffictypediagnostic: AM4PR07MB1364: x-ms-office365-filtering-correlation-id: e0cac40e-d1f3-4fd7-d104-08d4acaf1cf9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR07MB1364; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(43073073696351); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB1364; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB1364; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39860400002)(39400400002)(39450400003)(39850400002)(39840400002)(53754006)(377454003)(13464003)(66654002)(24454002)(2950100002)(50986999)(6506006)(93886004)(8936002)(6436002)(8676002)(81166006)(478600001)(5890100001)(6486002)(2906002)(7736002)(66066001)(53546009)(3660700001)(305945005)(229853002)(86362001)(25786009)(3280700002)(54356999)(76176999)(5660300001)(14454004)(6916009)(6246003)(36756003)(966005)(38730400002)(53936002)(2900100001)(110136004)(6116002)(230783001)(102836003)(189998001)(99286003)(5250100002)(82746002)(3846002)(33656002)(6306002)(6512007)(83716003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1364; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 07:39:07.0064 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1364 Archived-At: Subject: Re: [ippm] R: WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 07:39:13 -0000 SSBoYWQgYSByZWFkIHRocm91Z2ggdGhlIGRyYWZ0LCBhbmQgY2FuIGFncmVlIHdpdGggdGhlIHBy b2dyZXNzIG9mIGRyYWZ0LWlldGYtaXBwbS1hbHQtbWFyayANCg0KS2luZCBSZWdhcmRzLA0KRy8N Cg0KT24gMDUvMDYvMjAxNywgMTc6MjYsICJpcHBtIG9uIGJlaGFsZiBvZiBTdWRoaW4gSmFjb2Ii IDxpcHBtLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHNqYWNvYkBqdW5pcGVyLm5ldD4g d3JvdGU6DQoNCiAgICBIaSBBbGwsDQogICAgDQogICAgSSBzdXBwb3J0IHRoaXMgZHJhZnQuIEkg dGhpbmsgaXQgaXMgZ29vZCBmb3IgcHVibGljYXRpb24uDQogICAgDQogICAgUmVnYXJkcywNCiAg ICBTdWRoaW4NCiAgICANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206 IGlwcG0gW21haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5k ZXIgQ2xlbW0NCiAgICBTZW50OiBUaHVyc2RheSwgSnVuZSAxLCAyMDE3IDExOjEyIFBNDQogICAg VG86IEZpb2Njb2xhIEdpdXNlcHBlIDxnaXVzZXBwZS5maW9jY29sYUB0ZWxlY29taXRhbGlhLml0 PjsgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNoPjsgSUVURiBJUFBNIFdH IDxpcHBtQGlldGYub3JnPg0KICAgIFN1YmplY3Q6IFJlOiBbaXBwbV0gUjogV0dMQyBvbiBkcmFm dC1pZXRmLWlwcG0tYWx0LW1hcmsNCiAgICANCiAgICBJIHRoaW5rIHRoaXMgaXMgcmVhZHkgZm9y IHB1YmxpY2F0aW9uLiANCiAgICANCiAgICAgSSBoYXZlIG9ubHkgb25lIHZlcnkgbWlub3IgZWRp dG9yaWFsIG5pdCByZWdhcmRpbmcgZG9jdW1lbnQgc3RydWN0dXJlOiAgVGhlcmUgaXMgYSBzZWN0 aW9uIDMuMS4xIGJ1dCBubyBzZWN0aW9uIDMuMS4yLiAgSSB0aGluayBpdCBpcyBwcmVmZXJhYmxl IHRvIGhhdmUgZWl0aGVyIGF0IGxlYXN0IHR3byBzdWJzZWN0aW9ucywgb3Igbm9uZSBhdCBhbGwu ICBJIHVuZGVyc3RhbmQgdGhhdCAzLjEgaXMgYSBsb25nIHNlY3Rpb24gdGhhdCBtYXkgcmVxdWly ZSBicmVha2luZyB1cC4gIEl0IHNlZW1zIHRoYXQgMy4xLjEgY291bGQgYWN0dWFsbHkgYmUgZWxl dmF0ZWQgb25lIGxldmVsIHRvIGJlY29tZSAzLjIuICANCiAgICANCiAgICBLaW5kIHJlZ2FyZHMN CiAgICAtLS0gQWxleA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAg RnJvbTogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEZp b2Njb2xhIEdpdXNlcHBlDQogICAgU2VudDogVGh1cnNkYXksIEp1bmUgMDEsIDIwMTcgMToxOSBB TQ0KICAgIFRvOiBCcmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+OyBJRVRG IElQUE0gV0cgPGlwcG1AaWV0Zi5vcmc+DQogICAgU3ViamVjdDogW2lwcG1dIFI6IFdHTEMgb24g ZHJhZnQtaWV0Zi1pcHBtLWFsdC1tYXJrDQogICAgDQogICAgSGkgSVBQTWVycywNCiAgICBGaXJz dCwgSSB3YW50IHRvIHRoYW5rIElQUE0gY2hhaXJzIGZvciBzdGFydGluZyBXR0xDIHBoYXNlLg0K ICAgIEkgdGhpbmsgdGhlIGRvY3VtZW50IGlzIHN0YWJsZSBhbmQgY29uc29saWRhdGVkIGluIHRl cm1zIG9mIGNvbnRlbnQgYW5kIHNjb3BlLg0KICAgIEkgc3VwcG9ydCBpdHMgcHVibGljYXRpb24g KGFzIGNvLWF1dGhvciksIGFsc28gYmVjYXVzZSB0aGVyZSBhcmUgcmVsYXRlZCB1c2UgY2FzZXMs IGFscmVhZHkgcHJlc2VudGVkIHdpdGhpbiBJRVRGLCB0aGF0IG5lZWQgYSByZWZlcmVuY2UgZG9j dW1lbnQuDQogICAgDQogICAgQmVzdCBSZWdhcmRzLA0KICAgIA0KICAgIEdpdXNlcHBlDQogICAg DQogICAgLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCiAgICBEYTogaXBwbSBbbWFpbHRv OmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIEJyaWFuIFRyYW1tZWxsIChJRVRG KQ0KICAgIEludmlhdG86IG1hcnRlZMOsIDMwIG1hZ2dpbyAyMDE3IDE3OjUzDQogICAgQTogSUVU RiBJUFBNIFdHDQogICAgT2dnZXR0bzogW2lwcG1dIFdHTEMgb24gZHJhZnQtaWV0Zi1pcHBtLWFs dC1tYXJrDQogICAgDQogICAgR3JlZXRpbmdzLCBJUFBNLA0KICAgIA0KICAgIEFzIGRpc2N1c3Nl ZCBpbiBDaGljYWdvLCB0aGlzIG1lc3NhZ2UgYmVnaW5zIGEgV29ya2luZyBHcm91cCBMYXN0IENh bGwgb24gZHJhZnQtaWV0Zi1pcHBtLWFsdC1tYXJrLCB0byAgdG8gcnVuIHVudGlsIEVPQiBDRVNU IChVVEMgKzIpIFR1ZXNkYXkgMjAgSnVuZSAyMDE3LiBQbGVhc2UgcmVwbHkgdG8gaXBwbUBpZXRm Lm9yZyBpbmRpY2F0aW5nIHdoZXRoZXIgeW91IGJlbGlldmUgdGhpcyBkb2N1bWVudCBpcyByZWFk eSBmb3IgcHVibGljYXRpb24sIGFuZCBpZiBub3QsIHdoeSBub3QuDQogICAgDQogICAgTWFueSB0 aGFua3MsIGJlc3QgcmVnYXJkcywNCiAgICANCiAgICBCcmlhbiAoYXMgSVBQTSBjby1jaGFpcikN CiAgICANCiAgICBRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJp enphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25l LCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2Vu emEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVh bG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBj b3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBt aXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gDQog ICAgDQogICAgVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwg YW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBh ZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNl IGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNo bWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4gDQog ICAgDQogICAgUmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNl IG5vbiDDqCBuZWNlc3NhcmlvLg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICAgaXBwbSBtYWlsaW5nIGxpc3QNCiAgICBpcHBtQGll dGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQog ICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICBpcHBtIG1haWxpbmcgbGlzdA0KICAgIGlwcG1AaWV0Zi5vcmcNCiAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCiAgICANCiAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIGlwcG0gbWFpbGluZyBsaXN0 DQogICAgaXBwbUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXBwbQ0KICAgIA0KDQo= From nobody Tue Jun 6 03:56:04 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88234127011 for ; Tue, 6 Jun 2017 03:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 WdHku4RIX7Xv for ; Tue, 6 Jun 2017 03:56:02 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C8912426E for ; Tue, 6 Jun 2017 03:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3712; q=dns/txt; s=iport; t=1496746561; x=1497956161; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5bfsMnwEYbwMQKPnXdMGzuKF+g0wz8LBZ7UkMqw1dUk=; b=QMLaI7QAqCHWcrZjpAtSthuEz8hYHMu1UsRmymznugSjIrMcVadf1ij4 w2PDUwXQBVwaRiQ+oEEqnDfiMr8IsTggym3Fmva+mUU+E2F0jHVdvm/Ca mvUXEb8CvOtZKahQWz+f0zYNa8lKSZFHMCfMskIQJvUDToSp82gSgClzh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRAAATiTZZ/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0Hg2yKGZIClX+CECELhXgCGoJSPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEbBhE6EAcEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQBEgiKGggQr?= =?us-ascii?q?TOCJowEAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VWgWCDIId8gmEFnjQChyS?= =?us-ascii?q?DN4hOgg+FPoo7lGABHziBCnQVRocGdog/gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.39,306,1493683200"; d="scan'208";a="252342067" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2017 10:55:59 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v56AtxWg000301 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Jun 2017 10:55:59 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Jun 2017 05:55:58 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1210.000; Tue, 6 Jun 2017 05:55:58 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "Brian Trammell (IETF)" , "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for draft-brockners-inband-oam-data Thread-Index: AQHS2R1BNaTDADeGaUWeDcjDyZXwdKIXtAVg Date: Tue, 6 Jun 2017 10:55:58 +0000 Message-ID: References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> In-Reply-To: <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.26.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 10:56:03 -0000 SGVsbG8gQnJpYW4vIGFsbCwNCiAgIEFzIGFuIGltcGxlbWVudGVyIG9mIHRoZSBpbmJhbmQtb2Ft LWRhdGEgZHJhZnQgKGZkLmlvKSwgSSBzdXBwb3J0IHRoZSBXRyBhZG9wdGlvbiBvZiB0aGlzIGRv Y3VtZW50LiBJIHN1Z2dlc3QgdGhhdCB0aGlzIGJlIGNvbnNpZGVyZWQgZm9yIFN0YW5kYXJkcyB0 cmFjayBpbnN0ZWFkIG9mIHRoZSBleHBlcmltZW50YWwgdHJhY2sgc2luY2Ugd2UgaGF2ZSB3b3Jr aW5nIGNvZGUgb2YgSU9BTSBhY3Jvc3MgdGhyZWUgZGlmZmVyZW50IHRyYW5zcG9ydCBwcm90b2Nv bHMgKElQdjYsIFZ4TEFOLUdQRSBhbmQgTlNIKS4NClRoYW5rcw0KUHJhc2FkDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpcHBtIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gVHJhbW1lbGwgKElFVEYpDQpTZW50OiBUdWVzZGF5LCBN YXkgMzAsIDIwMTcgMTo0OCBQTQ0KVG86IGlwcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFtpcHBtXSBB ZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhDQoNCkdyZWV0 aW5ncywgSVBQTSwNCg0KQXQgb3VyIENoaWNhZ28gbWVldGluZywgd2UgZGVjaWRlZCB3ZSBuZWVk ZWQgYSBzaW5nbGUsIGNsZWFuZWQtdXAgZG9jdW1lbnQgY29udGFpbmluZyBhcHByb3ByaWF0ZSBz Y29waW5nIGFuZCByYXRpb25hbGUgaW4gb3JkZXIgdG8gbWFrZSBhIGRlY2lzaW9uIGFzIHRvIHdo ZXRoZXIgd2UnZCBsaWtlIHRvIGFkb3B0IElPQU0gd2l0aGluIElQUE0uIFRoaXMgcmV2aXNpb24g b2YgZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YSBpcyB0aGF0IGRvY3VtZW50Lg0KDQpU aGlzIG1lc3NhZ2UsIHRoZXJlZm9yZSwgc3RhcnRzIGEgY2FsbCBmb3IgYWRvcHRpb24gb24gZHJh ZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YSwgdG8gcnVuIHVudGlsIEVPQiBDRVNUIChVVEMg KzIpIFR1ZXNkYXkgMjAgSnVuZSAyMDE3LiBQbGVhc2UgcmVwbHkgdG8gaXBwbUBpZXRmLm9yZyBp bmRpY2F0aW5nOg0KDQooMSkgd2hldGhlciB5b3Ugc3VwcG9ydCBhZGRpdGlvbiBvZiB0aGUgZm9s bG93aW5nIG1pbGVzdG9uZSB0byB0aGUgSVBQTSBjaGFydGVyOg0KDQpkYXRlIFRCRDogU3VibWl0 IGFuIEV4cGVyaW1lbnRhbCBkcmFmdCBvbiBpbmJhbmQgT0FNIGJhc2VkIG1lYXN1cmVtZW50IG1l dGhvZG9sb2dpZXMgdG8gdGhlIElFU0cNCg0KKDIpIHdoZXRoZXIgeW91IHN1cHBvcnQgdGhlIGFk b3B0aW9uIG9mIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEtMDUgYXMgdGhlIGJhc2lz IGRvY3VtZW50IGZvciB0aGlzIG1pbGVzdG9uZQ0KDQooMykgd2hldGhlciB5b3UgY29tbWl0IHRv IHJldmlld2luZyB0aGUgZG9jdW1lbnQgaWYgYWRvcHRlZA0KDQoNCldlIGFyZSBhd2FyZSB0aGF0 IHRoZXJlIGlzIGFuIG9wZW4gcXVlc3Rpb24gYXMgdG8gd2hldGhlciB3ZSBjYW4gYWRvcHQgZHJh ZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YSB1bmRlciBvdXIgY3VycmVudCBjaGFydGVyOyB3 ZSdkIGxpa2UgdG8gc2VlIGlmIHRoZXJlIGlzIElQUE0gV0cgY29uc2Vuc3VzIG9uIGFkb3B0aW9u IGJlZm9yZSBkaXNjdXNzaW5nIGEgcmVjaGFydGVyLCBob3BlZnVsbHkgYmVmb3JlIFByYWd1ZSwg dGhvdWdoIHdlIGNhbiB0YWtlIGZhY2UtdG8tZmFjZSB0aW1lIGluIFByYWd1ZSBmb3IgdGhpcyBp ZiBuZWNlc3NhcnkuIE91ciBpbnRlbnRpb24sIGFzIGNoYWlycywgaXMgdG8gbWFrZSB0aGUgbWlu aW1hbCBuZWNlc3NhcnkgY2hhbmdlIHRvIHRoZSBjaGFydGVyIHNob3VsZCB0aGVyZSBiZSBjb25z ZW5zdXMgZm9yIGFkb3B0aW9uLiBIb3dldmVyLCBpZiB5b3UgaGF2ZSBwYXJ0aWN1bGFyIG9waW5p b25zIGFzIHRvIGhvdyB0aGlzIHNob3VsZCBiZSBkb25lLCBwbGVhc2UgYWxzbyBhZGRyZXNzIHRo ZXNlIGluIHlvdXIgbWVzc2FnZS4NCg0KTWFueSB0aGFua3MsIGJlc3QgcmVnYXJkcywNCg0KQnJp YW4gKGFzIElQUE0gY28tY2hhaXIpDQoNCg0KDQo+IE9uIDI5IE1heSAyMDE3LCBhdCAxNzoyNiwg RnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSkgPGZicm9ja25lQGNpc2NvLmNvbT4gd3JvdGU6DQo+ IA0KPiBEZWFyIElQUE0gV0csDQo+IA0KPiB3ZeKAmXZlIGp1c3QgcG9zdGVkIGFuIHVwZGF0ZWQg dmVyc2lvbiBvZiBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhOiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS0wNSB3aGljaCBp cyB0byBhZGRyZXNzIHRoZSByZWNlbnQgY29tbWVudHMgb24gdGhlIG1haWxpbmcgbGlzdC4gVGhl IG1haW4gY2hhbmdlIGlzIHRoZSB2ZXJiaWFnZSBhcm91bmQgdGhlIG5lZWQgdG8gZW5zdXJlIHRo YXQgSU9BTSBkYXRhIGlzIGtlcHQgd2l0aGluIHRoZSBJT0FNIGRvbWFpbi4gSW4gYWRkaXRpb24s IHNldmVyYWwgZWRpdG9yaWFsIG5pdHMgaGF2ZSBiZWVuIGNsZWFuZWQgdXAuDQo+IA0KPiBXZSBh cHByZWNpYXRlIHlvdXIgdGhvdWdodHMgYW5kIGNvbW1lbnRzLg0KPiANCj4gUmVnYXJkcywgRnJh bmsNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IGlwcG0gbWFpbGluZyBsaXN0DQo+IGlwcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCg== From nobody Tue Jun 6 07:59:06 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4060126D05 for ; Tue, 6 Jun 2017 07:59:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 b3KbHENmGEgs for ; Tue, 6 Jun 2017 07:59:03 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4371293F4 for ; Tue, 6 Jun 2017 07:59:03 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id a2so17068004oth.2 for ; Tue, 06 Jun 2017 07:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FD7AvR1NjqYuNgUQMUNkvQPI2p8VBA3xr09B+xH7q0k=; b=qP0QEJI/Xrjdg4+bKd8iBAnNndvK8nil/Tj+7jyAnGqDG6ErS94wBuIBkTBhif+IsL NDedN7rhvgfzt7QG0xFCsJEdGPFfi+8fQ3Oeeaze9LARqWvp3EgKE8vjabBYCA8CdSrb jXyyr+/JxSwmcTnZlqC0ILezSfYz91VSIF83O0NQ+CmacWRJ+IvDnYjTYT0l1xaFOPN+ nxeBkEQO4c3UFkizy5qr2bFd025/GsnupKd8964LwTDE7raetB4e6SsAW4VEWnjZ4SUO DFT+5J2ZJGcVBXrhjRMeIrEC0xXKnx9c5zfkJoHaz9Pz+Ptv0JoFU1pBggc7ietAU+hf dHfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FD7AvR1NjqYuNgUQMUNkvQPI2p8VBA3xr09B+xH7q0k=; b=c+Gd9aXLRTwJxGlNNEE/WdBObE+OaA5hl15j7UNQCex2XuyDCpD2nF1Ou9/fKKcQka 08m4HZd1SfCvAe1yr2Ncd/nU+/pYzIH76zPVMUa9ucNN7f8dCbVVjKmBLNTCcssFmQUJ G4br3vuGPXQNNoL5zf4vlNcyU+9EuNqvz6jEWqla+WrERWIRSRUNdkKDTrVxAz88CELN CyvpbqjgicYqTD++2GHMmuiNyKZ3/eoqpABin+G66B8A8kLW70u/Nk/uG0eXXu782Fak DOewxZH99rzHyjrmyXabrdg/aSXEylTtjz672AWxgc6pEJfyaeSR0U0NkiGGO7SCbLQK IMVg== X-Gm-Message-State: AODbwcBXnUS4VNA7zKABjExmJDnO86e0GrTPEjBgj6X4gYpQsU8brt8L 0LMrmmUX1Rhbk54lEY6yAEQf3eUuXA== X-Received: by 10.157.82.88 with SMTP id q24mr13389379otg.52.1496761142341; Tue, 06 Jun 2017 07:59:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.225 with HTTP; Tue, 6 Jun 2017 07:59:01 -0700 (PDT) In-Reply-To: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> From: Greg Mirsky Date: Tue, 6 Jun 2017 07:59:01 -0700 Message-ID: To: "Brian Trammell (IETF)" Cc: IETF IPPM WG Content-Type: multipart/alternative; boundary="f4030435bc1833f72b05514bdc14" Archived-At: Subject: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 14:59:06 -0000 --f4030435bc1833f72b05514bdc14 Content-Type: text/plain; charset="UTF-8" Hi Brian, WG community, I believe that the document is ready for publication. The Alternate Marking method is useful and mature technology to measure performance metrics. Several WGs in the Routing Area are working on adapting the Alternate Marking method as passive PM OAM. As co-author I'm committed to work on it and address all the comments throughout the publication process. Regards, Greg On Tue, May 30, 2017 at 8:53 AM, Brian Trammell (IETF) wrote: > Greetings, IPPM, > > As discussed in Chicago, this message begins a Working Group Last Call on > draft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday 20 > June 2017. Please reply to ippm@ietf.org indicating whether you believe > this document is ready for publication, and if not, why not. > > Many thanks, best regards, > > Brian (as IPPM co-chair) > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --f4030435bc1833f72b05514bdc14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian, WG community,
I believe that the document is= ready for publication. The Alternate Marking method is useful and mature t= echnology to measure performance metrics. Several WGs in the Routing Area a= re working on adapting the Alternate Marking method as passive PM OAM.
As co-author I'm committed to work on it and address all the comm= ents throughout the publication process.

Regards,<= /div>
Greg=C2=A0

On Tue, May 30, 2017 at 8:53 AM, Brian Trammell (IETF) <ie= tf@trammell.ch> wrote:
Gree= tings, IPPM,

As discussed in Chicago, this message begins a Working Group Last Call on d= raft-ietf-ippm-alt-mark, to=C2=A0 to run until EOB CEST (UTC +2) Tuesday 20= June 2017. Please reply to ippm@ietf.org<= /a> indicating whether you believe this document is ready for publication, = and if not, why not.

Many thanks, best regards,

Brian (as IPPM co-chair)

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


--f4030435bc1833f72b05514bdc14-- From nobody Tue Jun 6 08:35:51 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304001294F3 for ; Tue, 6 Jun 2017 08:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 CCVqID2Ex34T for ; Tue, 6 Jun 2017 08:35:48 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9AF1294E8 for ; Tue, 6 Jun 2017 08:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2771; q=dns/txt; s=iport; t=1496763348; x=1497972948; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xViNqXY4uGHZtpRv2TIqfpDMsi0MpbKmR2MGCa3vbgE=; b=RcqV/PiNrGxKdelFszzgR3TKwT24R0uM3CIz8lDTyE+QO0wqFj6TNrTN 02CInCTEpCYb/97xY3dpaUwMWl074C7nIdKLBLtVpyi54hMnuNpqPkeZf 9HTuyrpRk3nBTkX16JgCmhVElwg2ZJsScfdu83ACujb1Rzxpsqk/P7J8a s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAADeyjZZ/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0HjgWSBJV/ghAhC4V4AoJjPxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQMBARtRFwQCAQgRBAEBAScHJwsUCQgCBAESiioQr0aLfgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFiEGDIIpdBZB3jT0ChySDN4hXggaFPoNuhk2UYAEfOIEKdBV?= =?us-ascii?q?GhwZ2iD+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,306,1493683200"; d="scan'208";a="434386512" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2017 15:35:47 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v56FZkcY013807 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Jun 2017 15:35:47 GMT Received: from xch-rtp-008.cisco.com (64.101.220.148) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Jun 2017 11:35:45 -0400 Received: from xch-rtp-008.cisco.com ([64.101.220.148]) by XCH-RTP-008.cisco.com ([64.101.220.148]) with mapi id 15.00.1210.000; Tue, 6 Jun 2017 11:35:46 -0400 From: "Srihari Raghavan (srihari)" To: "Brian Trammell (IETF)" , "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for draft-brockners-inband-oam-data Thread-Index: AQHS3rOEI9kfCc2asUuyiBmPQR7QJqIYlvkA Date: Tue, 6 Jun 2017 15:35:46 +0000 Message-ID: References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.83.69] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1833576A36C3224CB4CF35EA8E8F1E0B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 15:35:50 -0000 All, Having read the draft, I support the WG adoption of this document. I can review the document as needed, upon adoption. Thanks Srihari >-----Original Message----- >From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell >(IETF) >Sent: Tuesday, May 30, 2017 1:48 PM >To: ippm@ietf.org >Subject: [ippm] Adoption call for draft-brockners-inband-oam-data > >Greetings, IPPM, > >At our Chicago meeting, we decided we needed a single, cleaned-up >document containing appropriate scoping and rationale in order to make a >decision as to whether we'd like to adopt IOAM within IPPM. This revision >of draft-brockners-inband-oam-data is that document. > >This message, therefore, starts a call for adoption on >draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday >20 June 2017. Please reply to ippm@ietf.org indicating: > >(1) whether you support addition of the following milestone to the IPPM >charter: > >date TBD: Submit an Experimental draft on inband OAM based measurement >methodologies to the IESG > >(2) whether you support the adoption of >draft-brockners-inband-oam-data-05 as the basis document for this >milestone > >(3) whether you commit to reviewing the document if adopted > > >We are aware that there is an open question as to whether we can adopt >draft-brockners-inband-oam-data under our current charter; we'd like to >see if there is IPPM WG consensus on adoption before discussing a >recharter, hopefully before Prague, though we can take face-to-face time >in Prague for this if necessary. Our intention, as chairs, is to make the >minimal necessary change to the charter should there be consensus for >adoption. However, if you have particular opinions as to how this should >be done, please also address these in your message. > >Many thanks, best regards, > >Brian (as IPPM co-chair) > > > >> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) >> wrote: >>=20 >> Dear IPPM WG, >>=20 >> we=B9ve just posted an updated version of >>draft-brockners-inband-oam-data: >>https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is >>to address the recent comments on the mailing list. The main change is >>the verbiage around the need to ensure that IOAM data is kept within the >>IOAM domain. In addition, several editorial nits have been cleaned up. >>=20 >> We appreciate your thoughts and comments. >>=20 >> Regards, Frank >>=20 >> _______________________________________________ >> 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 From nobody Tue Jun 6 10:03:30 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A26129AE9 for ; Tue, 6 Jun 2017 10:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 pVJM2AOS50if for ; Tue, 6 Jun 2017 10:03:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55AE8129ACD for ; Tue, 6 Jun 2017 10:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5006; q=dns/txt; s=iport; t=1496768602; x=1497978202; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WIqLq9p+qQrp6urshMfXpGW+WDZ/pZ4FQgdpDinmEmQ=; b=IfnaQJz3VnVNq12Y2gBb17IZdm4SVbpEkUSYrg2RlMTBZJzpLCqPWSqq X8nTP3Wlg5a+GvBi1xuk/xPzDbrpcXhfd5soNuvI3r7aBrOfTmLyNUkSF DgqCr+Vf/5ocChbWmOk5dUg26lSb8M8RPI483ATmZm2lfKwTRAqilNOZ7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAAAL4DZZ/5JdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0Hg2yKGZIFlX+CECELhXgCGoJKPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEhETMHCwULAgEIGAICJgICAiULFAEQAgQOBYoiCBCtPoImi30BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhVaBYCuBaYEMh3yCYQWdZk4ChySMDoI?= =?us-ascii?q?GhT6KO5RgAR84gQp0FRwqEgGGc3YBiD6BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,306,1493683200"; d="scan'208";a="257353497" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2017 17:03:06 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v56H36O6028444 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Jun 2017 17:03:06 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Jun 2017 13:03:05 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Tue, 6 Jun 2017 13:03:05 -0400 From: "Carlos Pignataro (cpignata)" To: "Brian Trammell (IETF)" CC: IETF IPPM WG Thread-Topic: [ippm] WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2VzoGahGlx1gOUq0eoSBLxU0T6IYXdoA Date: Tue, 6 Jun 2017 17:03:05 +0000 Message-ID: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> In-Reply-To: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.49.152] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 17:03:29 -0000 QnJpYW4sDQoNCkkgc3VwcG9ydCBhZHZhbmNpbmcgdGhpcyBkb2N1bWVudCBhbmQgYmVsaWV2ZSBp dOKAmXMgcmVhZHkgdG8gYmUgc2VudCB0byB0aGUgSUVTRy4NCg0KVGhpcyBpcyBhbiBpbXBvcnRh bnQgZG9jdW1lbnQgYW5kIGZvdW5kYXRpb24gdG8gc3BlY2lmaWMgcHJvdG9jb2wgcmVhbGl6YXRp b25zLCBhbmQgaXRzIHF1YWxpdHkgaXMgdmVyeSBnb29kLiBJIGFsc28gYmVsaWV2ZSB0aGF0IEV4 cGVyaW1lbnRhbCwgYXMgY3VycmVudGx5IGludGVuZGVkLCBpcyBhcHByb3ByaWF0ZS4NCg0KSSBk byBoYXZlIGEgc2V0IG9mIGNvbW1lbnRzLCBmb3IgY29uc2lkZXJhdGlvbiBhcyBwYXJ0IG9mIHRo aXMgV0dMQy4NCg0KV2hpbGUgdGhlIG1ldGhvZCBpdHNlbGYgaXMgZGVzY3JpYmVkIGluIGdyZWF0 IGRldGFpbCBhbmQgd2l0aCBjYXJlLCBzb21lIGNvbnRleHR1YWwgaW5mb3JtYXRpb24gYW5kIHRl eHQgYXJvdW5kIGp1c3RpZmljYXRpb25zIG9yIHBvdGVudGlhbCBmdXR1cmUgaW1wbGVtZW50YXRp b24gaXMgYSBiaXQgbW9yZSBsb29zZS4NCg0KQ29tbWVudHM6DQoNCkEuIFRpdGxlIGFuZCBtZXRo b2QNCg0KVGhlIHRpdGxlIG9mIHRoaXMgZG9jdW1lbnQgaXMg4oCcQWx0ZXJuYXRlIE1hcmtpbmcg bWV0aG9kIGZvciBwYXNzaXZlIHBlcmZvcm1hbmNlIG1vbml0b3JpbmfigJ0uDQoNCkhvd2V2ZXIs IGFzIEdyZWcgTWlyc2t5IHJlcGVhdGVkbHkgbWVudGlvbmVkIGluIGRpZmZlcmVudCBjb250ZXh0 cywgbGV04oCZcyB1c2UgSUVURiBkZWZpbml0aW9ucyBvciBhY3RpdmUvcGFzc2l2ZS9pbmJhbmQv ZXRjLiBBcyBzdWNoLCBQYXNzaXZlIG1vbml0b3JpbmcgZG9lcyBub3QgbW9kaWZ5IHBhY2tldHMu DQoNCkJhc2VkIG9uIHRoZSBkZWZpbml0aW9uIGF0IFJGQyA3Nzk5ICh3aGljaCBpcyBub3QgcmVm ZXJlbmNlZCk6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3Nzk5I3NlY3Rpb24t My42DQozLjYuICBQYXNzaXZlIE1ldGhvZHMNCg0KICAgUGFzc2l2ZSBNZXRob2RzIG9mIE1lYXN1 cmVtZW50IGFyZToNCg0KICAgbyAgYmFzZWQgc29sZWx5IG9uIG9ic2VydmF0aW9ucyBvZiBhbiB1 bmRpc3R1cmJlZCBhbmQgdW5tb2RpZmllZA0KICAgICAgcGFja2V0IHN0cmVhbSBvZiBpbnRlcmVz dCAoaW4gb3RoZXIgd29yZHMsIHRoZSBtZXRob2Qgb2YNCiAgICAgIG1lYXN1cmVtZW50IE1VU1Qg Tk9UIGFkZCwgY2hhbmdlLCBvciByZW1vdmUgcGFja2V0cyBvciBmaWVsZHMgb3INCiAgICAgIGNo YW5nZSBmaWVsZCB2YWx1ZXMgYW55d2hlcmUgYWxvbmcgdGhlIHBhdGgpLg0KDQpTYXlpbmcg4oCc bWFya2luZyBmb3IgcGFzc2l2ZeKAnSBpcywgYmFzZWQgb24gdGhpcyBkZWZpbml0aW9uLCBhbiBv eHltb3Jvbi4gTWFya2luZyAvIGNvbG9yaW5nIHdvdWxkIGdvIGFnYWluc3QgdGhlIGRlZmluaXRp b24gb2YgcGFzc2l2ZS4NCg0KQi4gU3BlY2lmaWMgY29tbWVudHM6DQoNCjEuICBJbnRyb2R1Y3Rp b24NCg0KICAgTm93YWRheXMsIG1vc3Qgb2YgdGhlIHRyYWZmaWMgaW4gU2VydmljZSBQcm92aWRl cnMnIG5ldHdvcmtzIGNhcnJpZXMNCiAgIHJlYWwgdGltZSBjb250ZW50Lg0KDQpDTVA6IFdoaWxl IEkgZG8gbm90IGRpc3B1dGUgdGhhdCBzdGF0ZW1lbnQsIGEgY2l0YXRpb24gd291bGQgbm90IGh1 cnQgdG8gc3VwcG9ydCB0aGUgZGVmaW5pdGl2ZW5lc3Mgb2YgdGhlIHZlcnkgZmlyc3Qgc2VudGVu Y2Ugc2V0dGluZyB0aGUgdG9uZSBmb3IgdGhlIHdob2xlIGRvY3VtZW50Lg0KDQpDTVA6IFNlY3Rp b25zIDItNCBsb29rIGdyZWF0Lg0KDQpDTVA6IEkgdGhpbmsgdGhlcmUgYXJlIGlzc3VlcyBpbiBT ZWN0aW9uIDUuIFNlY3Rpb24gNSBzaG91bGQgY292ZXIgdGhlIGZvbGxvd2luZzoNCg0KICAgbyAg U2VjdGlvbiA1IHJlcG9ydHMgZXhhbXBsZXMgb2YgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1l bnQgb2YgdGhlDQogICAgICBtZXRob2QuICBGdXJ0aGVybW9yZSB0aGUgb3BlcmF0aW9uYWwgZXhw ZXJpbWVudCBkb25lIGF0IFRlbGVjb20NCiAgICAgIEl0YWxpYSBpcyBkZXNjcmliZWQ7DQoNCkNN UDogQW5kIFNlY3Rpb24gNS4xIGlzIHBlcmZlY3QgYW5kIGRlc2NyaWJlcyBleGFjdGx5IHRoZSBl eGFtcGxlIG9mIGltcGxlbWVudGF0aW9uLiBIb3dldmVyOg0KDQo1LjMuICBQZXJmb3JtYW5jZSBN ZWFzdXJlbWVudCBNYXJraW5nIE1ldGhvZCBpbiBCSUVSIERvbWFpbg0KDQpDTVA6IFRoZSBkcmFm dCBpbmhlcmVudGx5IGRlc2NyaWJlcyBhIHVuaWNhc3Qgc2VydmljZSwgbm90IHN1cmUgaWYgdGhp cyBkb2N1bWVudCBpcyBub3Qgc2NvcGVkIHRvIGNsYWltIHRoaXMgc3ViLXNlY3Rpb24uDQoNCjUu NC4gIE92ZXJsYXkgT0FNIFBhc3NpdmUgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQNCg0KICAgVGhl IE92ZXJsYXkgT0FNIERlc2lnbiBUZWFtIGlzIGNvbnNpZGVyaW5nIHRoZSBwcmVsaW1pbmFyeSBP QU0NCiAgIHJlcXVpcmVtZW50cyBmcm9tIE5WTzMsIEJJRVIsIGFuZCBTRkMuICBNYXJraW5nIE1l dGhvZCBpcyB0aGUNCiAgIHByZWZlcnJlZCBwYXNzaXZlIG1ldGhvZCB0byBtZWFzdXJlIHBlcmZv cm1hbmNlLg0KDQogICBbSS1ELm9vYW1kdC1ydGd3Zy1vb2FtLXJlcXVpcmVtZW50XSBhbmQNCiAg IFtJLUQub29hbWR0LXJ0Z3dnLW9hbS1nYXAtYW5hbHlzaXNdIGV4cGxhaW4gaW4gZGVlcCB0aGlz IGl0ZW0uDQoNCkNNUDogVGhpcyB0byBtZSBpcyBhIGdyb3NzIGV4dHJhcG9sYXRpb24uIFRoZSB0 ZXh0IGFzIHdyaXR0ZW4gaXMgc2ltcGx5IGluY29ycmVjdCwgYW5kIHRoZXJl4oCZcyBubyBtYXR1 cml0eSBvciBicm9hZCBhbGlnbm1lbnQgdG8gaW5jbHVkZSB0aGlzIEkgcmVjb21tZW5kIHJlbW92 aW5nIHRoaXMgd2hvbGUgU2VjdGlvbiA1LjQuDQpDTVA6IFRoaXMgaXMgbmVpdGhlciDigJxleGFt cGxlcyBvZiBpbXBsZW1lbnRhdGlvbiBvciBkZXBsb3ltZW504oCdLg0KDQoNCk5ldC1uZXQsIEkg c3VwcG9ydCB0aGlzIGRvY3VtZW50IGJ1dCByZWNvbW1lbmQgdGhlc2UgY29tbWVudHMgYXJlIGFk ZHJlc3NlZC4NCg0KVGhhbmtzLA0KDQrigJQgQ2FybG9zLg0KDQoNCg0KPiBPbiBNYXkgMzAsIDIw MTcsIGF0IDExOjUzIEFNLCBCcmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+ IHdyb3RlOg0KPiANCj4gR3JlZXRpbmdzLCBJUFBNLA0KPiANCj4gQXMgZGlzY3Vzc2VkIGluIENo aWNhZ28sIHRoaXMgbWVzc2FnZSBiZWdpbnMgYSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBk cmFmdC1pZXRmLWlwcG0tYWx0LW1hcmssIHRvICB0byBydW4gdW50aWwgRU9CIENFU1QgKFVUQyAr MikgVHVlc2RheSAyMCBKdW5lIDIwMTcuIFBsZWFzZSByZXBseSB0byBpcHBtQGlldGYub3JnIGlu ZGljYXRpbmcgd2hldGhlciB5b3UgYmVsaWV2ZSB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBw dWJsaWNhdGlvbiwgYW5kIGlmIG5vdCwgd2h5IG5vdC4NCj4gDQo+IE1hbnkgdGhhbmtzLCBiZXN0 IHJlZ2FyZHMsDQo+IA0KPiBCcmlhbiAoYXMgSVBQTSBjby1jaGFpcikNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gaXBwbSBtYWlsaW5nIGxpc3QN Cj4gaXBwbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwcG0NCg0K From nobody Tue Jun 6 10:05:58 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B549A129AE9; Tue, 6 Jun 2017 10:05:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149676875770.3878.3416885399887764152@ietfa.amsl.com> Date: Tue, 06 Jun 2017 10:05:57 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-6man-pdm-option-11.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 17:05:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics of the IETF. Title : IPv6 Performance and Diagnostic Metrics (PDM) Destination Option Authors : Nalini Elkins Robert M. Hamilton Michael S. Ackermann Filename : draft-ietf-ippm-6man-pdm-option-11.txt Pages : 31 Date : 2017-06-06 Abstract: To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-11 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-6man-pdm-option-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-6man-pdm-option-11 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 Jun 6 10:21:26 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A225129AEE for ; Tue, 6 Jun 2017 10:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.519 X-Spam-Level: X-Spam-Status: No, score=0.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=yahoo.com 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 RYa7Qsgul80o for ; Tue, 6 Jun 2017 10:21:24 -0700 (PDT) Received: from sonic302-30.consmr.mail.gq1.yahoo.com (sonic302-30.consmr.mail.gq1.yahoo.com [98.137.68.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1D31270FC for ; Tue, 6 Jun 2017 10:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1496769683; bh=5IaEt6aqWCGqzFrpEUfijrLzoQsWg/neJAqRRdT8874=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=rjeWHk0EVDQHyvactKsHN6BJkznQUsdR6PdxuPqdrQA1jBttiEVMEgHe07Cf7S05UMfPUg9swGA5sxjhcOM5FvT0kx+19VbPQqK/kCuw8GeJmueT5DRdxklyYVOkW6KOLvznwenQSHMeQov5YnhmFP2/T3IVwfFnz3EiS1j2rCtXN7ET9JJwkkJ/d17KEkrYYxotGqj/iOUsyPU/weIyniWO9mQxbBd6YCy2vbZd1pg2EG1ZxCDZV68KBLdjo6jA4USO+cBYvrGldjbWUlaePZFz1UFK0e3yubTLPZPmqsyHglw6MIQLf8+r82TgLwVwf0DhRddQVsxznqix14Ss0w== X-YMail-OSG: ay7xniQVM1mrnaweuP0iXu2aTuXsXzKr7X2HqqLLOWCaiDvVYaBP6x5T_lgGb_7 wKYR4ha4CdTNPdUacpssEAeoYjy6x3DA9jULtN1XE9q7DUj1UROcei7TQypG5CmdpH523yETsrId ovXCSqO5GCiibxGw.XTNh34qomwQi2IsShFRB1gXFSd21YXE0oh45Pb6DlfWf8mviKVddcHirqUl Eg7FLQXV9UeAmqTs5TKwZVuaks.G1NmzU7ypRNfc882y3CQJ0PELcwydkGqlLPzU3p3kCgg.IxF4 pBbQv6iTUzhrmpqRvUS3oawBIqvuby4UYedWooBWvasMoArTo0glx95QM4PSVeWZG7z1Wr4YLrhP e3DEj1HKpwFv..Ej0eMwaQKzAZx2KkVsUof_yPBvXxdFEElZPB_7wvELtqf_H1J2r.821hjnbt0t 3CZ7W_B5oMAZJFXJQaWRw77dxctfdlno0fwNjKNDp62bG5KEZGumVpgF1hCEP18LWnreRRM4sb4_ gxuxU4NdQerJFxyHI73oU9vNLnhFhxdJhEuAT9o9PSMF6_N8eFTzlT4Stt5xVM54bdmqicFGZhLG JQmHIB1u8XCnc1L0dU0VyKejdq5YJyPM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 Jun 2017 17:21:23 +0000 Date: Tue, 6 Jun 2017 17:11:21 +0000 (UTC) From: Reply-To: To: The IESG , Nalini J Elkins Cc: "draft-ietf-ippm-6man-pdm-option@ietf.org" , Al Morton , Bill Cerveny , "ippm-chairs@ietf.org" , "ippm@ietf.org" Message-ID: <1081965272.4091641.1496769081453@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <1081965272.4091641.1496769081453.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9778 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Archived-At: Subject: [ippm] draft-ietf-ippm-6man-pdm-option-11 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 17:21:25 -0000 All, I have posted draft-ietf-ippm-6man-pdm-option-11. I believe that we have addressed all IESG comments in this latest draft of PDM ( https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/). Please let me know if there is anything else left to do. If you would like for me to resend the copy of my responses to you, please let me know. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From nobody Tue Jun 6 11:05:26 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F101274D0; Tue, 6 Jun 2017 11:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8f1ML2CvuzJg; Tue, 6 Jun 2017 11:05:14 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D184E127241; Tue, 6 Jun 2017 11:05:14 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id u1so159194pfg.1; Tue, 06 Jun 2017 11:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JG8xgb2M3pcwIAl5CzrnoNSOhxYSih+TdqBOJusmQR4=; b=a8NQ63ZPsrAYi0KFbO4YGvgJOfE176apJ9Ouz3Zxqa8uo+c8ylSC358uw0SyE4tGjy o9y23SrtzMQxFyCjs0iPBOrFwKFzWSmqJgPHnBe2qOnzPmceDDSrdKslO4vED1DOmCZO OYJJKkR3i/D9WvaAR5adtskFPmqc1UYhr9w5toY/CYo9+lOl34IqnI8RnWOXitgl6Aw8 AstidMzia4nCeXRbvx52cWfwP0q6MxAmU3NV0Y5mgrN1Gj6aJGd/ScFyAqvuSxtZfwYR wZnzXs0wiTHgoq/MwntAtWvgW7cM+Dbae0uMdQ31ASLWoxY3y9aSYj2Cl4asL2C3xRmV pJmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JG8xgb2M3pcwIAl5CzrnoNSOhxYSih+TdqBOJusmQR4=; b=PiWzPK2F82JhLwegoq+h9XaQIhuvHawP7OZPX+G98hAyBcCQDaDCSkdFQgZ4VJ1DAX XDZRaGuvMPXZMRBQlmddcVXYaqx4SgU9DMygOAjgk4hW1Jaki0SQjI8HDA+csPB1qCe/ pNLisf4DPd6y6hfyPj3H23JuhUom9Ab/ducbHi9GIzr5CxPy2ZquF2ms2YKz6QqL+9bj RfVX53TyExFzffg5d7BWyuzb9eShKfRg5EKI3rLcMUkF4M1Uj5unmCgWExrNwk2Zk6n3 o8/YE9g9R0p8h5d4UlahUNYBUXC/1Ka4K68xb7fpbEzAUEr/hrWnGR+0kh8yYPYvmYKO vEOw== X-Gm-Message-State: AODbwcAfuIHvfw5MGJTzOiL/Ija7/73MydUnGo1vgl5DPWOG4JpwvR++ 2TbJu792vTk7GQ== X-Received: by 10.99.55.18 with SMTP id e18mr16186278pga.119.1496772314332; Tue, 06 Jun 2017 11:05:14 -0700 (PDT) Received: from [192.168.43.251] ([106.208.233.240]) by smtp.gmail.com with ESMTPSA id j71sm19855398pge.63.2017.06.06.11.05.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 11:05:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Suresh Krishnan In-Reply-To: <1081965272.4091641.1496769081453@mail.yahoo.com> Date: Tue, 6 Jun 2017 23:12:22 +0530 Cc: The IESG , "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , Al Morton , "ippm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <1081965272.4091641.1496769081453.ref@mail.yahoo.com> <1081965272.4091641.1496769081453@mail.yahoo.com> To: nalini.elkins@insidethestack.com X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ippm] draft-ietf-ippm-6man-pdm-option-11 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 18:05:19 -0000 Hi Nalini, I looked over the new version and it has fixed 3 out of the 4 points I = brought up (Thanks!). The alignment one still remains unaddressed. I = thought we agreed to an alignment requirement of 2n but the draft just = says "The alignment for PDM is per RFC2460 [RFC2460]=E2=80=9D which really says nothing since RFC2460 expects *this* document to state = the alignment requirement. Regards Suresh > On Jun 6, 2017, at 10:41 PM, nalini.elkins@insidethestack.com wrote: >=20 > All, >=20 > I have posted draft-ietf-ippm-6man-pdm-option-11. >=20 > I believe that we have addressed all IESG comments in this latest = draft of PDM ( = https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/). >=20 > Please let me know if there is anything else left to do. =20 >=20 > If you would like for me to resend the copy of my responses to you, = please let me know. >=20 > Thanks, >=20 > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 >=20 >=20 From nobody Tue Jun 6 13:44:38 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BE3129AAD for ; Tue, 6 Jun 2017 13:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.41 X-Spam-Level: X-Spam-Status: No, score=0.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 v2NzFrxNlP-O for ; Tue, 6 Jun 2017 13:44:34 -0700 (PDT) Received: from sonic318-28.consmr.mail.gq1.yahoo.com (sonic318-28.consmr.mail.gq1.yahoo.com [98.137.70.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E80129584 for ; Tue, 6 Jun 2017 13:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1496781874; bh=hqpemB2fmE8jPmHxlCRlgQv1B0eg/f2n1noqGhITBM4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=RPufcZl18831RVNWOd7qAnDan0wHHqLe3QGoEgBZTNV6m9namqwfPK6IPjZ4ym3/pMb+XuMjHKi/nvtGiFIODU6nQDhNTrC37MrD7kDgL3JYqfjyqdrTpkBWqUz6zFBavsOcVC5yjBrRkvgInqIQYGMwsVX4fztLha7hVje8RrTX+2zTdDPDVecEBB6mpUaJNae4z1FovG93o/3Fa0vx5UiAsvzBFGoaRG9G9JWoZDrsqZGS9xUXpbBWXa5UG7WzfAgn5PT8en2hpwDavVYzx1oa4NAVO68kbaUQN+5l39V4VKwa66KsoGMtQvhRC5WjT9JmdCAskJ0UaFcdXT4UtQ== X-YMail-OSG: 2Kr9tYkVM1mi8gsg2q6jK0tmtCYkJllvidSaKMxBAV4RfRzGICVxb2YUxftNLLq qTK0BcetqVP8dsE9kOid5iiAYeZnJCCjF7SAkH4TBDmCjGhagt0fQLD6c1AjFZt2bp5prx50E3zm R3TjFcrqJrddb2G_Jf5ICziVkaCVZ3Tfba7UcBOUeJGs0GwEK_yBn9v1NP1qX5RcbUhs00eLw4aG 37JugLkX0xeoGiWazcJkoJW5Njjzf.voJTklR5fw2TjB2G1lqgIsScxDZYlOGDHPv3LClugEvjFk ge1ic7PYBDYVY8XY2S7YJ4F863HwFEBjdKGQfBZMwd.uzSgfPaTKn0JWW9Wh8ImmYQDLLaVmGiqW iSJayHHMKkbbiM1far.ZGF1KRhd9qvIr00UzIffSijIy0WYVOltsKqiYU56Gi7yQiEmqTqcZ7jGn cE6Mg5JAFK89fY5z1BchrboYVJzDZ53A8mhkW7OdLSU4vCfWNLwdWaVkDlOLhb7bRzH24tcvXIER 3B.hS26LUrDrAEqXfynB2CchJJ640ZDWN7Y_ayZopFPf2D4f4w_7YtehNRT4LiV157vdjpt..D29 Onga_Tw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic318.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 Jun 2017 20:44:34 +0000 Date: Tue, 6 Jun 2017 20:44:28 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Suresh Krishnan Cc: The IESG , "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , Al Morton , "ippm@ietf.org" Message-ID: <1071027365.4388609.1496781868310@mail.yahoo.com> In-Reply-To: References: <1081965272.4091641.1496769081453.ref@mail.yahoo.com> <1081965272.4091641.1496769081453@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4388608_418196921.1496781868308" X-Mailer: WebService/1.1.9778 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Archived-At: Subject: Re: [ippm] draft-ietf-ippm-6man-pdm-option-11 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jun 2017 20:44:36 -0000 ------=_Part_4388608_418196921.1496781868308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Suresh, >=C2=A0I looked over the new version and it has fixed 3 out of the 4 points= I brought up (Thanks!). The alignment one still remains unaddressed. I tho= ught we=C2=A0 > agreed to an alignment requirement of 2n but the draft just says > "The alignment for PDM is per RFC2460 [RFC2460]=E2=80=9D > which really says nothing since RFC2460 expects *this* document to state = the alignment requirement. I looked at a number of the other RFCs which define Destination Options. = =C2=A0RFC6275 : Mobility Support in IPv6, Section 6.2.1 has: "Mobility options may have alignment requirements. Following the=C2=A0conve= ntion in IPv6, these options are aligned in a packet so that multi-octet va= lues within the Option Data field of each option fall on natural boundaries= (i.e., fields of width n octets are placed at an integer multiple of n oct= ets from the start of the header, for n =3D 1, 2, 4, or 8) [6]" If we use the same wording: OLD----"The alignment for PDM is per RFC2460 [RFC2460]=E2=80=9D New---"PDM has alignment requirements. Following the convention in IPv6, th= ese options are aligned in a packet so that multi-octet values within the O= ption Data field of each option fall on natural boundaries (i.e., fields of= width n octets are placed at an integer multiple of n octets from the star= t of the header, for n =3D 1, 2, 4, or 8) [RFC2460]"=C2=A0 =C2=A0Please let me know if you are OK with the changes and I will create a= new version. Thanks,Nalini > On Jun 6, 2017, at 10:41 PM, nalini.elkins@insidethestack.com wrote: >=20 > All, >=20 > I have posted draft-ietf-ippm-6man-pdm-option-11. >=20 > I believe that we have addressed all IESG comments in this latest draft o= f PDM ( https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/). >=20 > Please let me know if there is anything else left to do.=C2=A0=20 >=20 > If you would like for me to resend the copy of my responses to you, pleas= e let me know. >=20 > Thanks, >=20 > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 >=20 >=20 ------=_Part_4388608_418196921.1496781868308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Suresh,

> I looked over the new version and it h= as fixed 3 out of the 4 points I brought up (Thanks!). The alignment one st= ill remains unaddressed. I thought we 
> agreed to an alignment = requirement of 2n but the draft just says

> "The alignment for PD= M is per RFC2460 [RFC2460]=E2=80=9D

> which really says nothing since RFC2460 expects *this* doc= ument to state the alignment requirement.


<= /div>
I looked at a number of the other RFCs which define Destination Op= tions.  RFC6275 : Mobility Support in IPv6, Section 6.2.1 has:

=
"Mobility options may have alig= nment requirements. Following the convention in IPv6, these options a= re aligned in a packet so that multi-octet values within the Option Data fi= eld of each option fall on natural boundaries (i.e., fields of width n octe= ts are placed at an integer multiple of n octets from the start of the head= er, for n =3D 1, 2, 4, or 8) [6]"


If = we use the same wording:
OLD
----
"The alignment for PDM is per RFC246= 0 [RFC2460]=E2=80=9D

New=
---
"PDM has alignment requirem= ents. Following the convention in IPv6, these options are aligned in a pack= et so that multi-octet values within the Option Data field of each option f= all on natural boundaries (i.e., fields of width n octets are placed at an = integer multiple of n octets from the start of the header, for n =3D 1, 2, = 4, or 8) [RFC2460]" 


 Please let me know if you are OK with t= he changes and I will create a new version.

Thanks,
Nalini


> On Jun 6, 2017, at 10:41 PM, nalini= .elkins@insidethestack.com wrote:
>
> All,
>
> I = have posted draft-ietf-ippm-6man-pdm-option-11.
>
> I believe = that we have addressed all IESG comments in this latest draft of PDM ( http= s://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/).
> > Please let me know if there is anything else left to do. 
&g= t;
> If you would like for me to resend the copy of my responses to = you, please let me know.
>
> Thanks,
>
> Nalini E= lkins
> CEO and Founder
> Inside Products, Inc.
> www.ins= idethestack.com
> (831) 659-8360
>
>
------=_Part_4388608_418196921.1496781868308-- From nobody Wed Jun 7 08:17:40 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F15E1294CF for ; Wed, 7 Jun 2017 08:17:39 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 rrBbVhrVFJ57 for ; Wed, 7 Jun 2017 08:17:36 -0700 (PDT) Received: from mx04.telecomitalia.it (mx04.telecomitalia.it [217.169.121.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC4412946C for ; Wed, 7 Jun 2017 08:17:35 -0700 (PDT) X-AuditID: d9a97918-971ff70000006255-8b-5938190ea8bf Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx04.telecomitalia.it () with SMTP id 6C.6E.25173.E0918395; Wed, 7 Jun 2017 17:17:35 +0200 (CEST) From: Fioccola Giuseppe To: Alexander Clemm , "Brian Trammell (IETF)" , IETF IPPM WG Thread-Topic: [ippm] R: WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2v5hgoSciBVv40SZOwsEadrPRaIZLgXA Date: Wed, 7 Jun 2017 15:17:34 +0000 Message-ID: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> <84439d81137d4f149012965b01ef4e84@TELMBXB02RM001.telecomitalia.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0DFB2D55@SJCEML701-CHM.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DFB2D55@SJCEML701-CHM.china.huawei.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.230] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42Lh4vsjrcsvaRFpsOcGu8WJN0tYLDa2vGOz 6HnwjtmB2aPlyFtWjyVLfjJ5PNk/kyWAOYrLJiU1J7MstUjfLoErY8nu7cwFc8UrVj2YytbA OEm4i5GTQ0LAROLIsiuMXYxcHEICU5kk3hzaxw6SYBOwkTj46gQbiC0iUCPxtXUBmC0sYC4x 99dbRoi4pcS3rdOhaowkps7qZQWxWQRUJL4cnMAMYvMKBEpcfbWDHWLBJUaJrRPmMYEkOAXC JDZ/vQu2jFFAVmLC7kVgQ5kFxCVeTD/BDnGdgMSSPeeZIWxRiZeP/7FC2AYSW5fuY4GwFSX2 /jgAVSMjsfDIZFaIOXoSN6ZOYYOwtSWWLXwNdZCgxMmZT1gmMIrOQrJuFpKWWUhaZiFpWcDI sopRNLfCwESvJDUnNTk/N7MkMSczUS+zZBMjMHpurqyU2MHYvdb5EKMAB6MSD2+msEWkEGti WXFl7iFGCQ5mJRFePz6gEG9KYmVValF+fFFpTmrxIUZpDhYlcd5je80jhQTSE0tSs1NTC1KL YLJMHJxSDYxtZkfKLq622Pf3gOPjvGkfz1YbyqT7CqbN2Ne5bGbXFh5fa14Zo0Mlyof00me/ fe919vVetjNzBU5/mMnxYvXdpWte9P7w7i2wDAk+3LzYkUfRwzH2osAmKV6nX1lnGPyC7qzQ k1p8X4sloraU4z/bB38dscLm30bFE+6FL+HYztWatXHf1PVKLMUZiYZazEXFiQCmNZhFmgIA AA== Archived-At: Subject: [ippm] R: R: WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 15:17:39 -0000 Thank you, Alex. It makes sense, section 3.1.1 could be elevated to become = 3.2. I will address this editorial change. Giuseppe -----Messaggio originale----- Da: Alexander Clemm [mailto:alexander.clemm@huawei.com]=20 Inviato: gioved=EC 1 giugno 2017 19:42 A: Fioccola Giuseppe; Brian Trammell (IETF); IETF IPPM WG Oggetto: RE: [ippm] R: WGLC on draft-ietf-ippm-alt-mark I think this is ready for publication.=20 I have only one very minor editorial nit regarding document structure: Th= ere is a section 3.1.1 but no section 3.1.2. I think it is preferable to h= ave either at least two subsections, or none at all. I understand that 3.1= is a long section that may require breaking up. It seems that 3.1.1 could= actually be elevated one level to become 3.2. =20 Kind regards --- Alex -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Fioccola Giuseppe Sent: Thursday, June 01, 2017 1:19 AM To: Brian Trammell (IETF) ; IETF IPPM WG Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark Hi IPPMers, First, I want to thank IPPM chairs for starting WGLC phase. I think the document is stable and consolidated in terms of content and sco= pe. I support its publication (as co-author), also because there are related us= e cases, already presented within IETF, that need a reference document. Best Regards, Giuseppe -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Brian Trammell (IETF) Inviato: marted=EC 30 maggio 2017 17:53 A: IETF IPPM WG Oggetto: [ippm] WGLC on draft-ietf-ippm-alt-mark Greetings, IPPM, As discussed in Chicago, this message begins a Working Group Last Call on d= raft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday 20 June= 2017. Please reply to ippm@ietf.org indicating whether you believe this do= cument is ready for publication, and if not, why not. Many thanks, best regards, Brian (as IPPM co-chair) Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.=20 This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.=20 Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Wed Jun 7 08:44:46 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D9B129474 for ; Wed, 7 Jun 2017 08:44:44 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 E5fup-pThNn2 for ; Wed, 7 Jun 2017 08:44:42 -0700 (PDT) Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (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 0025F128959 for ; Wed, 7 Jun 2017 08:44:41 -0700 (PDT) X-AuditID: d9a97916-c63ff70000009b0d-56-59381f6600a2 Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id A3.30.39693.66F18395; Wed, 7 Jun 2017 17:44:39 +0200 (CEST) From: Fioccola Giuseppe To: Qin Wu , "Brian Trammell (IETF)" , IETF IPPM WG Thread-Topic: [ippm] WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2Vzpj3BlOYX4YUisNIH+0MLyVqIVYLkAgAPRd8A= Date: Wed, 7 Jun 2017 15:44:38 +0000 Message-ID: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.230] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="gb2312" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsXCxfdHWjdd3iLS4PoOHYvHcxewWmxsecdm 0fPgHbMDs0fLkbesHkuW/GTyeLJ/JksAc1QDo01iXl5+SWJJqkJKanGyrZJLZnFyTmJmbmqR QkhqTmpyfq6SQmaKrZKxkkJBTmJyam5qXomtUmJBQWpeipIdlwIGsAEqy8xTSM1Lzk/JzEu3 VfIM9te1sDC11DVUsgssTS0uyVfITS0uTkxPz8xXSE1YL5jx5fQU5oI7qhVnf1xhamB8oNLF yMEhIWAi8bCTu4uRi0NIYCqTxKFVK5m6GDk52ARsJA6+OsEGYosIZEscebgAzBYWMJbYu20h O0TcVGL2l1WsELaVxISbfWA2i4CKxMODV1lA5vMKBEpMmpMIMb+LUWJ+2zM2kDinQJjE+Uni IOWMArISE3YvYgSxmQXEJV5MPwE2XkJAQGLJnvPMELaoxMvH/1ghbAOJrUv3sUDYihJ7fxyA qpGRWHhkMivEHC2JeQ2/mSBsRYkp3Q/BZvIKCEqcnPmEZQKj6Cwk62YhaZmFpGUWkpYFjCyr GEVzKwyM9EogMZZZkpiTmaiXWbKJEZgmbq6sFNvB2LrW+RCjAAejEg+vn6BFpBBrYllxZe4h RgkOZiURXj8+oBBvSmJlVWpRfnxRaU5q8SFGH2CATWSWEk3OB6awvJJ4QxMLS0NjCwsjQwsz UxzCSuK8x/aaRwoJpAOTVHZqakFqEcw4Jg5OqQZGSf+SiC931jxqVjij1ra///GE7tN6OxQ3 L1t55oDsCvkNOS33a7e2/l92siqn5den1GkKHnWLl3udOMGjmRLUXJgUlx50uO+OZuL/cjmj /xE/i5WXnPLyWBiw67WmkaZayderW43Fph77/63oy0OeY6VH8ibdKmTrUL5p9fzaen3DiSf0 VPbHKbEUZyQaajEXFScCAEh6c+5AAwAA Archived-At: Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 15:44:45 -0000 UWluLCBUaGFua3MgZm9yIHlvdXIgc3VwcG9ydC4NCkFuc3dlcnMgaW5saW5lIHRhZ2dlZCBh cyBbR0ZdLg0KDQpHaXVzZXBwZQ0KDQotLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0K RGE6IFFpbiBXdSBbbWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbV0gDQpJbnZpYXRvOiBsdW5l ZKisIDUgZ2l1Z25vIDIwMTcgMDM6MjUNCkE6IEJyaWFuIFRyYW1tZWxsIChJRVRGKTsgSUVU RiBJUFBNIFdHDQpDYzogRmlvY2NvbGEgR2l1c2VwcGUNCk9nZ2V0dG86IFJFOiBbaXBwbV0g V0dMQyBvbiBkcmFmdC1pZXRmLWlwcG0tYWx0LW1hcmsNCg0KSSBoYXZlIHJlLXJlYWQgdGhp cyBkb2N1bWVudCBhbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uDQpI ZXJlIGFyZSBhIGZldyBtaW5vciBjb21tZW50cyBhcyBmb2xsb3dzOg0KMS4gSSBmZWVsIGRp c2Nvbm5lY3RlZCB3aGVuIEkgcmVhZCB0aGUgbGFzdCBzZW50ZW5jZSBvZiBmbG93IGJhc2Vk IHN0cmF0ZWd5IHNlY3Rpb246DQoiDQogICAgICBBbm90aGVyIGFwcGxpY2F0aW9uDQogICAg ICBpcyBvbiBNb2JpbGUgQmFja2hhdWxpbmcsIGltcGxlbWVudGVkIHdpdGggYSBWUE4gTVBM UyBpbiBUZWxlY29tDQogICAgICBJdGFsaWEncyBuZXR3b3JrOyBpbiB0aGlzIGNhc2UgdGhl IHByb2JsZW0gd2l0aCB1bmljYXN0IHRyYWZmaWMgaXMNCiAgICAgIG92ZXJjb21lIGJ5IG1v bml0b3JpbmcganVzdCB0aGUgdHdvIFByb3ZpZGVyIEVkZ2Ugbm9kZXMgb2YgdGhlIFZQTg0K ICAgICAgTVBMUy4NCiINCkhvdyB0aGlzIGlzIHJlbGF0ZWQgdG8gZmxvdyBiYXNlZCBjYXNl PyBIb3cgZG8geW91IGFkZHJlc3MgbG9hZC1iYWxhbmNpbmcgaXNzdWUgaW4gTW9iaWxlIGJh Y2toYXVsaW5nIGNhc2UgYnkgbW9uaXRvcmluZyB0d28gUEVzIG5vZGVzLg0KSSBzdXBwb3Nl IHRoZXJlIGFyZSBtdWx0aXBsZSBob3BzIGJldHdlZW4gdHdvIFBFIG5vZGVzLCBJIGFzc3Vt ZSBsYWJlbCBlbnRyb3B5IG1heSBiZSB1c2VkIHRvIGFkZHJlc3MgbG9hZCBiYWxhbmNpbmcg aXNzdWUuDQoNCltHRl06IFRoaXMgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gaXMgbm90IGRl dGFpbGVkIHNvIG11Y2ggaGVyZSBiZWNhdXNlIGlzIG91dCBvZiBzY29wZSwgYnV0IGl0IGlz IHBlcmZvcm1lZCBvbiBlYWNoIGZsb3cgYmV0d2VlbiB0d28gb3IgbW9yZSBQRXMgYW5kIG5v dCBpbiB0aGUgTVBMUyBjbG91ZC4gVGhlIGZsb3dzIGFyZSBpZGVudGlmaWVkIGFuZCBmaWx0 ZXJlZCBieSB1c2luZyBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIElQIGFkZHJlc3Nlcy4gSW4g dGhlIG1pZGRsZSB0aGVyZSBpcyBubyB3YXkgdG8gbWFrZSBkZWVwIHBhY2tldCBpbnNwZWN0 aW9uIHRvIGNvdW50IHRoZSBtYXJrZWQgRFNDUCBmaWVsZCBhbmQgdGhlIG1vbml0b3Jpbmcg c2hvdWxkIGJlIGRvbmUgYnkgdXNpbmcgUkZDNjM3NCBTRkwuIEluIGNhc2Ugb2YgbG9hZC1i YWxhbmNpbmcgd2UgYXJlIGluIGEgbXVsdGlwb2ludCBzaXR1YXRpb24gYW5kIGl0IGlzIHBv c3NpYmxlIHRvIGNvdXBsZSB0aGUgY291bnRlcnMuDQoNCjIuIEFzIGRlc2NyaWJlZCBpbiB0 aGlzIGRyYWZ0LCBUcmFmZmljIGNvbG9yaW5nIGNhbiBiZSBpbXBsZW1lbnRlZCBieSBzZXR0 aW5nIGEgc3BlY2lmaWMgYml0IGluIHRoZSAgcGFja2V0IGhlYWRlciBhbmQgY2hhbmdpbmcg dGhlIHZhbHVlIG9mIHRoYXQgYml0IHBlcmlvZGljYWxseS4gQnV0IGl0IGxvb2tzIGluIHRo aXMgZHJhZnQsIHRyYWZmaWMgY29sb3JpbmcgaXMgb25seSBzdXBwb3J0ZWQgYnkgc2V0dGlu ZyBhIHNwZWNpZmljIGJpdCBvZiBRb1MgcmVsYXRlZCBmaWVsZCBzdWNoIGFzIERTQ1AgZmll bGQuDQogSXMgdGhpcyByZWFsIGludGVudGlvbiBvciB5b3UgY2FuIHN1cHBvcnQgb3RoZXIg dHJhZmZpYyBjb2xvciBhcyB3ZWxsPw0KDQpbR0ZdOiBUaGUgRFNDUCBtYXJraW5nIGZpZWxk IGlzIGp1c3QgYW4gZXhhbXBsZS4gV2UgdXNlZCB0aGlzIGZpZWxkIG9ubHkgYmVjYXVzZSB0 aGUgY3VycmVudCByb3V0ZXIgY2FwYWJpbGl0aWVzIGVuYWJsZSB0byBtYXJrIGFuZCBjb3Vu dCBiYXNlZCBvbiBEU0NQIGZpZWxkIGluIGEgc2ltcGxlIHdheS4gU2VjdGlvbiA1LjIsIDUu MywgNS40LCA1LjUsIDUuNiBkZXNjcmliZSB0aGUgZXhpc3RpbmcgVXNlIENhc2VzLCBmb3Ig ZXhhbXBsZSBpbiBCSUVSIHlvdSBoYXZlIHR3byBkZWRpY2F0ZWQgYW5kIHJlc2VydmVkIGJp dHMgZm9yIG1hcmtpbmcgbWV0aG9kLg0KDQozLkFzIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0 LCB0d28gZW5jb2RpbmdzIG9mIHRoZSBEU0NQIGZpZWxkIGNhbiBiZSB1c2VkIHRvIGNvbG9y IHRoZSBwYWNrZXRzPyBXaGF0IGRvIHlvdSBtZWFuIGJ5IHR3byBlbmNvZGluZywgaWYgbXkg dW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB5b3UgdXNlIG9uZSBiaXQgKGJpdCAxKSBvZiB0 aGUgRFNDUCBmaWxlZCB0byBjb2xvciB0aGUgcGFja2V0cywgb25lIGJpdCAoYml0IDApIHRv IGluZGljYXRlIGZsb3cgdW5kZXIgdHJhZmZpYyBtb25pdG9yaW5nLg0KIFdoZW4gYml0IDEg aXMgc2V0IHRvIDAsIGl0IGNvcnJlc3BvbmRzIHRvIGNvbG9yIEEsIHdoZW4gYml0MSBpcyBz ZXQgdG8gMSwgaXQgY29ycmVzcG9uZHMgdG8gY29sb3IgQiwgSXMgYml0MSBzZXQgdG8gMCBj b3JyZXNwb25kaW5nIHRvIG9uZSBlbmNvZGluZyB3aGlsZSBiaXQxIHNldCB0byAxIGNvcnJl c3BvbmRpbmcgdG8gdGhlIG90aGVyIGVuY29kaW5nPw0KDQpbR0ZdOiBZZXMsIGJ1dCB0aGlz IGlzIGp1c3QgYSBkZXNjcmlwdGlvbiBvZiB0aGUgZXhwZXJpbWVudCBpbiBUSSBuZXR3b3Jr LiBGb3IgaW5zdGFuY2UgaW4gSVBGUE0gdGhlICJldmlsIGJpdCIgaXMgcHJvcG9zZWQgZm9y IG1hcmtpbmcuDQoNCjQuIFNlY3Rpb24gNS4xLjIgdGhlIDJuZCBwYXJhZ3JhcGgNCnMvYSBj b3VwbGUgb2QgY291bnRlcnMvYSBjb3VwbGUgb2YgY291bnRlcnMNCg0KW0dGXTogb2sNCg0K LVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IGlwcG0gW21haWx0bzppcHBtLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gQnJpYW4gVHJhbW1lbGwgKElFVEYpDQq3osvNyrG85Dog MjAxN8TqNdTCMzDI1SAyMzo1Mw0KytW8/sjLOiBJRVRGIElQUE0gV0cNCtb3zOI6IFtpcHBt XSBXR0xDIG9uIGRyYWZ0LWlldGYtaXBwbS1hbHQtbWFyaw0KDQpHcmVldGluZ3MsIElQUE0s DQoNCkFzIGRpc2N1c3NlZCBpbiBDaGljYWdvLCB0aGlzIG1lc3NhZ2UgYmVnaW5zIGEgV29y a2luZyBHcm91cCBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1pcHBtLWFsdC1tYXJrLCB0byAg dG8gcnVuIHVudGlsIEVPQiBDRVNUIChVVEMgKzIpIFR1ZXNkYXkgMjAgSnVuZSAyMDE3LiBQ bGVhc2UgcmVwbHkgdG8gaXBwbUBpZXRmLm9yZyBpbmRpY2F0aW5nIHdoZXRoZXIgeW91IGJl bGlldmUgdGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24sIGFuZCBpZiBu b3QsIHdoeSBub3QuDQoNCk1hbnkgdGhhbmtzLCBiZXN0IHJlZ2FyZHMsDQoNCkJyaWFuIChh cyBJUFBNIGNvLWNoYWlyKQ0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRp IHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRl LiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZh bnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29y b3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1 bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBp bW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxs YSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWlu YXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5h dXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2Ug dGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuIA0KDQpSaXNwZXR0YSBsJ2Ft YmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIOggbmVjZXNzYXJpby4N Cg== From nobody Wed Jun 7 09:11:46 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ABF1294B3 for ; Wed, 7 Jun 2017 09:11:44 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Zl0B9BnwaxP4 for ; Wed, 7 Jun 2017 09:11:41 -0700 (PDT) Received: from mx03.telecomitalia.it (mx03.telecomitalia.it [217.169.121.23]) (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 C32B7129477 for ; Wed, 7 Jun 2017 09:11:40 -0700 (PDT) X-AuditID: d9a97917-861ff7000000af2c-46-593825ba686d Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx03.telecomitalia.it () with SMTP id C9.B2.44844.AB528395; Wed, 7 Jun 2017 18:11:39 +0200 (CEST) From: Fioccola Giuseppe To: "Carlos Pignataro (cpignata)" , "Brian Trammell (IETF)" CC: IETF IPPM WG Thread-Topic: [ippm] WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2Vzpj3BlOYX4YUisNIH+0MLyVqIX+UWAgAE7WmA= Date: Wed, 7 Jun 2017 16:11:38 +0000 Message-ID: <8eae12d5997b4b50b774299b06f0c7c7@TELMBXB02RM001.telecomitalia.local> References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.230] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRmVeSWpSXmKPExsXCxfdHSne3qkWkwf3PTBaf3u1gsdjY8o7N oufBO2YHZo8pvzeyeixZ8pPJ48n+mSwBzFENjDaJeXn5JYklqQopqcXJtkoumcXJOYmZualF CiGpOanJ+blKCpkptkrGSgoFOYnJqbmpeSW2SokFBal5KUp2XAoYwAaoLDNPITUvOT8lMy/d Vskz2F/XwsLUUtdQyS6wNLW4JF8hN7W4ODE9PTNfITVhvWDG6rc/mQs+GFe8mbiQrYHxiFEX IyeHhICJxJWnl9m7GLk4hASmMklcvbKNDSTBJmAjcfDVCTBbRCBFYv7n54wgNrOAgsSjNU2s ILawgLHE3m0L2SFqTCVmf1nFCmFbSex81AJWzyKgIvHk4UQWEJtXIFBiXsMMMFtIoFDi5P23 YPM5BWwlpr15BjaHUUBWYsLuRVC7xCVeTD/BDnGogMSSPeeZIWxRiZeP/7FC2AYSW5fuY4Gw FSX2/jgAVSMjsfDIZKAaDqA5mhLrd+lDjFSUmNL9kB3iHEGJkzOfsExgFJuFZNsshI5ZSDpm IelYwMiyilE0t8LAWK8EEnuZJYk5mYl6mSWbGIHp4+bKSvEdjO0rnQ8xCnAwKvHwSspbRAqx JpYVV+YeYpTgYFYS4fXjAwrxpiRWVqUW5ccXleakFh9i9AGG10RmKdHkfGBqyyuJNzSxsDQ0 trAwMrQwM8UhrCTOe2yveaSQQDoweWWnphakFsGMY+LglGpgzLrSvmefh8YqhnWLzu9pfCsc sfa9kJlmpGBi238nx2dvFl9g4OBvNa4qOaf2doES19SsHfvOSBQtNqk7L3pRz/zofLv2JbvX s/lo7XtdPuFxb9Fd9zW3Gu7U3fv90sfFx6DotIHiZ0flswkn61skwj/a9Et6rz5sf4Bx5WUe PcOcyKaKdccWK7EUZyQaajEXFScCAOzISl5MAwAA Archived-At: Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 16:11:44 -0000 VGhhbmtzIGZvciB0aGUgc3VwcG9ydCwgQ2FybG9zLg0KQW5zd2VycyB0byB5b3VyIGNvbW1l bnRzIGFyZSBpbmxpbmUgdGFnZ2VkIGFzIFtHRl0uDQoNCkdpdXNlcHBlDQoNCi0tLS0tTWVz c2FnZ2lvIG9yaWdpbmFsZS0tLS0tDQpEYTogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0Bp ZXRmLm9yZ10gUGVyIGNvbnRvIGRpIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0KSW52 aWF0bzogbWFydGVkw6wgNiBnaXVnbm8gMjAxNyAxOTowMw0KQTogQnJpYW4gVHJhbW1lbGwg KElFVEYpDQpDYzogSUVURiBJUFBNIFdHDQpPZ2dldHRvOiBSZTogW2lwcG1dIFdHTEMgb24g ZHJhZnQtaWV0Zi1pcHBtLWFsdC1tYXJrDQoNCkJyaWFuLA0KDQpJIHN1cHBvcnQgYWR2YW5j aW5nIHRoaXMgZG9jdW1lbnQgYW5kIGJlbGlldmUgaXTigJlzIHJlYWR5IHRvIGJlIHNlbnQg dG8gdGhlIElFU0cuDQoNClRoaXMgaXMgYW4gaW1wb3J0YW50IGRvY3VtZW50IGFuZCBmb3Vu ZGF0aW9uIHRvIHNwZWNpZmljIHByb3RvY29sIHJlYWxpemF0aW9ucywgYW5kIGl0cyBxdWFs aXR5IGlzIHZlcnkgZ29vZC4gSSBhbHNvIGJlbGlldmUgdGhhdCBFeHBlcmltZW50YWwsIGFz IGN1cnJlbnRseSBpbnRlbmRlZCwgaXMgYXBwcm9wcmlhdGUuDQoNCkkgZG8gaGF2ZSBhIHNl dCBvZiBjb21tZW50cywgZm9yIGNvbnNpZGVyYXRpb24gYXMgcGFydCBvZiB0aGlzIFdHTEMu DQoNCldoaWxlIHRoZSBtZXRob2QgaXRzZWxmIGlzIGRlc2NyaWJlZCBpbiBncmVhdCBkZXRh aWwgYW5kIHdpdGggY2FyZSwgc29tZSBjb250ZXh0dWFsIGluZm9ybWF0aW9uIGFuZCB0ZXh0 IGFyb3VuZCBqdXN0aWZpY2F0aW9ucyBvciBwb3RlbnRpYWwgZnV0dXJlIGltcGxlbWVudGF0 aW9uIGlzIGEgYml0IG1vcmUgbG9vc2UuDQoNCkNvbW1lbnRzOg0KDQpBLiBUaXRsZSBhbmQg bWV0aG9kDQoNClRoZSB0aXRsZSBvZiB0aGlzIGRvY3VtZW50IGlzIOKAnEFsdGVybmF0ZSBN YXJraW5nIG1ldGhvZCBmb3IgcGFzc2l2ZSBwZXJmb3JtYW5jZSBtb25pdG9yaW5n4oCdLg0K DQpIb3dldmVyLCBhcyBHcmVnIE1pcnNreSByZXBlYXRlZGx5IG1lbnRpb25lZCBpbiBkaWZm ZXJlbnQgY29udGV4dHMsIGxldOKAmXMgdXNlIElFVEYgZGVmaW5pdGlvbnMgb3IgYWN0aXZl L3Bhc3NpdmUvaW5iYW5kL2V0Yy4gQXMgc3VjaCwgUGFzc2l2ZSBtb25pdG9yaW5nIGRvZXMg bm90IG1vZGlmeSBwYWNrZXRzLg0KDQpCYXNlZCBvbiB0aGUgZGVmaW5pdGlvbiBhdCBSRkMg Nzc5OSAod2hpY2ggaXMgbm90IHJlZmVyZW5jZWQpOg0KDQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzc5OSNzZWN0aW9uLTMuNg0KMy42LiAgUGFzc2l2ZSBNZXRob2RzDQoN CiAgIFBhc3NpdmUgTWV0aG9kcyBvZiBNZWFzdXJlbWVudCBhcmU6DQoNCiAgIG8gIGJhc2Vk IHNvbGVseSBvbiBvYnNlcnZhdGlvbnMgb2YgYW4gdW5kaXN0dXJiZWQgYW5kIHVubW9kaWZp ZWQNCiAgICAgIHBhY2tldCBzdHJlYW0gb2YgaW50ZXJlc3QgKGluIG90aGVyIHdvcmRzLCB0 aGUgbWV0aG9kIG9mDQogICAgICBtZWFzdXJlbWVudCBNVVNUIE5PVCBhZGQsIGNoYW5nZSwg b3IgcmVtb3ZlIHBhY2tldHMgb3IgZmllbGRzIG9yDQogICAgICBjaGFuZ2UgZmllbGQgdmFs dWVzIGFueXdoZXJlIGFsb25nIHRoZSBwYXRoKS4NCg0KU2F5aW5nIOKAnG1hcmtpbmcgZm9y IHBhc3NpdmXigJ0gaXMsIGJhc2VkIG9uIHRoaXMgZGVmaW5pdGlvbiwgYW4gb3h5bW9yb24u IE1hcmtpbmcgLyBjb2xvcmluZyB3b3VsZCBnbyBhZ2FpbnN0IHRoZSBkZWZpbml0aW9uIG9m IHBhc3NpdmUuDQoNCltHRl06IEFncmVlLCB0aGlzIGlzIGFuIGltcG9ydGFudCBwb2ludCB3 ZSBzaG91bGQgY2xhcmlmeSB0b2dldGhlciB3aXRoIElQUE0uIEEgcmVmZXJlbmNlIHRvIFJG Qzc3OTkgY2FuIGJlIGFkZGVkLiBJbiBteSBvcGluaW9uLCBtYXJraW5nIG1ldGhvZCBjb3Vs ZCBiZSBjb25zaWRlcmVkIGh5YnJpZCBvciBwYXNzaXZlIGRlcGVuZGluZyBvbiB0aGUgY2Fz ZS4gSW4gY2FzZSB0aGUgbWFya2luZyBiaXRzIGFyZSBwYXJ0IG9mIHRoZSBEU0NQIGZpZWxk IChhcyBhbiBleGFtcGxlKSB0aGUgdGVjaG5pcXVlIGlzIGh5YnJpZC4gSW4gY2FzZSB0aGUg bWFya2luZyBiaXRzIGFyZSBkZWRpY2F0ZWQgYW5kIHJlc2VydmVkIGFuZCBhcmUgaW5jbHVk ZWQgaW4gdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24gKGUuZy4gQklFUikgbWFya2luZyB0 ZWNobmlxdWUgY2FuIGJlIGNvbnNpZGVyZWQgYXMgcGFzc2l2ZS4gSSBzdWdnZXN0IHRvIGFk ZCBhbHNvIGh5YnJpZCBpbiB0aGUgdGl0bGUuDQoNCkIuIFNwZWNpZmljIGNvbW1lbnRzOg0K DQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIE5vd2FkYXlzLCBtb3N0IG9mIHRoZSB0cmFmZmlj IGluIFNlcnZpY2UgUHJvdmlkZXJzJyBuZXR3b3JrcyBjYXJyaWVzDQogICByZWFsIHRpbWUg Y29udGVudC4NCg0KQ01QOiBXaGlsZSBJIGRvIG5vdCBkaXNwdXRlIHRoYXQgc3RhdGVtZW50 LCBhIGNpdGF0aW9uIHdvdWxkIG5vdCBodXJ0IHRvIHN1cHBvcnQgdGhlIGRlZmluaXRpdmVu ZXNzIG9mIHRoZSB2ZXJ5IGZpcnN0IHNlbnRlbmNlIHNldHRpbmcgdGhlIHRvbmUgZm9yIHRo ZSB3aG9sZSBkb2N1bWVudC4NCg0KW0dGXTogQWdyZWUsIHdlIGNhbiBleHRlbmQgdGhpcyBz dGF0ZW1lbnQuDQoNCkNNUDogU2VjdGlvbnMgMi00IGxvb2sgZ3JlYXQuDQoNCkNNUDogSSB0 aGluayB0aGVyZSBhcmUgaXNzdWVzIGluIFNlY3Rpb24gNS4gU2VjdGlvbiA1IHNob3VsZCBj b3ZlciB0aGUgZm9sbG93aW5nOg0KDQogICBvICBTZWN0aW9uIDUgcmVwb3J0cyBleGFtcGxl cyBvZiBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudCBvZiB0aGUNCiAgICAgIG1ldGhv ZC4gIEZ1cnRoZXJtb3JlIHRoZSBvcGVyYXRpb25hbCBleHBlcmltZW50IGRvbmUgYXQgVGVs ZWNvbQ0KICAgICAgSXRhbGlhIGlzIGRlc2NyaWJlZDsNCg0KQ01QOiBBbmQgU2VjdGlvbiA1 LjEgaXMgcGVyZmVjdCBhbmQgZGVzY3JpYmVzIGV4YWN0bHkgdGhlIGV4YW1wbGUgb2YgaW1w bGVtZW50YXRpb24uIEhvd2V2ZXI6DQoNCjUuMy4gIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50 IE1hcmtpbmcgTWV0aG9kIGluIEJJRVIgRG9tYWluDQoNCkNNUDogVGhlIGRyYWZ0IGluaGVy ZW50bHkgZGVzY3JpYmVzIGEgdW5pY2FzdCBzZXJ2aWNlLCBub3Qgc3VyZSBpZiB0aGlzIGRv Y3VtZW50IGlzIG5vdCBzY29wZWQgdG8gY2xhaW0gdGhpcyBzdWItc2VjdGlvbi4NCg0KW0dG XTogSGVyZSBpcyBhbiBleGFtcGxlIG9uIGhvdyB0byB1c2UgdGhpcyBtZXRob2QgYXMgcGFz c2l2ZS4NCg0KNS40LiAgT3ZlcmxheSBPQU0gUGFzc2l2ZSBQZXJmb3JtYW5jZSBNZWFzdXJl bWVudA0KDQogICBUaGUgT3ZlcmxheSBPQU0gRGVzaWduIFRlYW0gaXMgY29uc2lkZXJpbmcg dGhlIHByZWxpbWluYXJ5IE9BTQ0KICAgcmVxdWlyZW1lbnRzIGZyb20gTlZPMywgQklFUiwg YW5kIFNGQy4gIE1hcmtpbmcgTWV0aG9kIGlzIHRoZQ0KICAgcHJlZmVycmVkIHBhc3NpdmUg bWV0aG9kIHRvIG1lYXN1cmUgcGVyZm9ybWFuY2UuDQoNCiAgIFtJLUQub29hbWR0LXJ0Z3dn LW9vYW0tcmVxdWlyZW1lbnRdIGFuZA0KICAgW0ktRC5vb2FtZHQtcnRnd2ctb2FtLWdhcC1h bmFseXNpc10gZXhwbGFpbiBpbiBkZWVwIHRoaXMgaXRlbS4NCg0KQ01QOiBUaGlzIHRvIG1l IGlzIGEgZ3Jvc3MgZXh0cmFwb2xhdGlvbi4gVGhlIHRleHQgYXMgd3JpdHRlbiBpcyBzaW1w bHkgaW5jb3JyZWN0LCBhbmQgdGhlcmXigJlzIG5vIG1hdHVyaXR5IG9yIGJyb2FkIGFsaWdu bWVudCB0byBpbmNsdWRlIHRoaXMgSSByZWNvbW1lbmQgcmVtb3ZpbmcgdGhpcyB3aG9sZSBT ZWN0aW9uIDUuNC4NCkNNUDogVGhpcyBpcyBuZWl0aGVyIOKAnGV4YW1wbGVzIG9mIGltcGxl bWVudGF0aW9uIG9yIGRlcGxveW1lbnTigJ0uDQoNCltHRl06IFllcywgdGhpcyBpcyBpbmhl cml0ZWQgYnkgb2xkIHZlcnNpb25zIG9mIHRoZSBkb2N1bWVudC4gSXQgd2lsbCBiZSBkZWxl dGVkIG9yIHJlcGhyYXNlZC4NCg0KDQpOZXQtbmV0LCBJIHN1cHBvcnQgdGhpcyBkb2N1bWVu dCBidXQgcmVjb21tZW5kIHRoZXNlIGNvbW1lbnRzIGFyZSBhZGRyZXNzZWQuDQoNClRoYW5r cywNCg0K4oCUIENhcmxvcy4NCg0KDQoNCj4gT24gTWF5IDMwLCAyMDE3LCBhdCAxMTo1MyBB TSwgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNoPiB3cm90ZToNCj4g DQo+IEdyZWV0aW5ncywgSVBQTSwNCj4gDQo+IEFzIGRpc2N1c3NlZCBpbiBDaGljYWdvLCB0 aGlzIG1lc3NhZ2UgYmVnaW5zIGEgV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gZHJhZnQt aWV0Zi1pcHBtLWFsdC1tYXJrLCB0byAgdG8gcnVuIHVudGlsIEVPQiBDRVNUIChVVEMgKzIp IFR1ZXNkYXkgMjAgSnVuZSAyMDE3LiBQbGVhc2UgcmVwbHkgdG8gaXBwbUBpZXRmLm9yZyBp bmRpY2F0aW5nIHdoZXRoZXIgeW91IGJlbGlldmUgdGhpcyBkb2N1bWVudCBpcyByZWFkeSBm b3IgcHVibGljYXRpb24sIGFuZCBpZiBub3QsIHdoeSBub3QuDQo+IA0KPiBNYW55IHRoYW5r cywgYmVzdCByZWdhcmRzLA0KPiANCj4gQnJpYW4gKGFzIElQUE0gY28tY2hhaXIpDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGlwcG0g bWFpbGluZyBsaXN0DQo+IGlwcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQppcHBtIG1haWxpbmcgbGlzdA0KaXBwbUBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNClF1ZXN0byBt ZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFt ZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVh bHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVz dGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFi YmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRl c2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1p dHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLiAN Cg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5k IG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBh ZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3Ig dXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBh bnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWws IFRoYW5rcy4gDQoNClJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEg bWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg== From nobody Wed Jun 7 09:52:23 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBF312869B for ; Wed, 7 Jun 2017 09:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oRQkbzKarU80 for ; Wed, 7 Jun 2017 09:52:20 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23074126C83 for ; Wed, 7 Jun 2017 09:52:20 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id u12so12794734qth.0 for ; Wed, 07 Jun 2017 09:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JqIWdvloOZQwPefYqcBN6lJaKRni29z4b+heAi7ANpE=; b=mE+NLVQAk5269eQXem6gQsTc3WlhkwOmbj06oADhXiy7TD7L/LyFOk3cMeulcr09+g BrlL3t0aB+bpXES9uxO7ZxMB8Nd1e/LNvqUnpSVl746IEDdUo4txDOd1iSYW9u6yNgrr 0YyXeUewLal7kgFWKSPWGEvyp4AN3vypotutlmCERxef4Y53fvqCJh7seBiN93jHv2ZD VVjWMFVOOeqzJkPuJ9OGAH5YbYSAO2+au/jcgDgrnE9ztEw6FKqrt84m1lr+oOPM4k5/ PaVP0XWxsgpe6zVuKkY7syPz3vHhOqPNl9ywM2mrs0VZCwmO2OWtzaC50cQmVdEKgQb4 fIag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=JqIWdvloOZQwPefYqcBN6lJaKRni29z4b+heAi7ANpE=; b=YGYrCTQXZw4wbqN0TczbXqym9bmhhoeNZGgqrqycFcLnU/MpS6Vg9SzlLlByPKPsgJ Tb7OxpOnin5A808R0e576pfiCic7PSTBver6yqKCW2g3fggb4i3i4pPzpy/Lg4cbHCxZ s+A05SiwAYjk8GDg7MsZ4TZ7pkd/YGU6ZV7BjY9e/WHyjBeyZUMB839rKKqCN8vSNISI vASNsAWz2Z8C1v/Ov+zo5D6ZNfecGI6PFWA/uaRn6TFUs7brEnJZSec67/5clb71q+vb Ukun5OIWUJ1wz4Um3kPAHbZ++tTacEj5GyOv8joN09iKm36l7fhEetVqtKDMlg5gObpJ QxxA== X-Gm-Message-State: AODbwcAUxNG6yAJKft4hBP/UhRk9pTOL34L7yyT7gpHG6rGpCvse+FrN myyIQOmsmThVRUe726ECDg== X-Received: by 10.55.8.144 with SMTP id 138mr38833550qki.25.1496854339183; Wed, 07 Jun 2017 09:52:19 -0700 (PDT) Received: from rtp-cpignata-nitro2.cisco.com ([173.38.117.81]) by smtp.gmail.com with ESMTPSA id p52sm1345230qtb.69.2017.06.07.09.52.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 09:52:18 -0700 (PDT) Sender: Carlos Pignataro Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carlos Pignataro In-Reply-To: <8eae12d5997b4b50b774299b06f0c7c7@TELMBXB02RM001.telecomitalia.local> Date: Wed, 7 Jun 2017 12:52:18 -0400 Cc: "Brian Trammell (IETF)" , IETF IPPM WG X-Mao-Original-Outgoing-Id: 518547138.507796-30ed133725655a9999afb9c9b9097b3a Content-Transfer-Encoding: quoted-printable Message-Id: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> <8eae12d5997b4b50b774299b06f0c7c7@TELMBXB02RM001.telecomitalia.local> To: Fioccola Giuseppe X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 16:52:22 -0000 Ciao, Giuseppe, Happy to support this document. I agree with all your responses. Please find a couple followups inline. > On Jun 7, 2017, at 12:11 PM, Fioccola Giuseppe = wrote: >=20 > Thanks for the support, Carlos. > Answers to your comments are inline tagged as [GF]. >=20 > Giuseppe >=20 > -----Messaggio originale----- > Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Carlos Pignataro = (cpignata) > Inviato: marted=C3=AC 6 giugno 2017 19:03 > A: Brian Trammell (IETF) > Cc: IETF IPPM WG > Oggetto: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark >=20 > Brian, >=20 > I support advancing this document and believe it=E2=80=99s ready to be = sent to the IESG. >=20 > This is an important document and foundation to specific protocol = realizations, and its quality is very good. I also believe that = Experimental, as currently intended, is appropriate. >=20 > I do have a set of comments, for consideration as part of this WGLC. >=20 > While the method itself is described in great detail and with care, = some contextual information and text around justifications or potential = future implementation is a bit more loose. >=20 > Comments: >=20 > A. Title and method >=20 > The title of this document is =E2=80=9CAlternate Marking method for = passive performance monitoring=E2=80=9D. >=20 > However, as Greg Mirsky repeatedly mentioned in different contexts, = let=E2=80=99s use IETF definitions or active/passive/inband/etc. As = such, Passive monitoring does not modify packets. >=20 > Based on the definition at RFC 7799 (which is not referenced): >=20 > https://tools.ietf.org/html/rfc7799#section-3.6 > 3.6. Passive Methods >=20 > Passive Methods of Measurement are: >=20 > o based solely on observations of an undisturbed and unmodified > packet stream of interest (in other words, the method of > measurement MUST NOT add, change, or remove packets or fields or > change field values anywhere along the path). >=20 > Saying =E2=80=9Cmarking for passive=E2=80=9D is, based on this = definition, an oxymoron. Marking / coloring would go against the = definition of passive. >=20 > [GF]: Agree, this is an important point we should clarify together = with IPPM. A reference to RFC7799 can be added. In my opinion, marking = method could be considered hybrid or passive depending on the case. In = case the marking bits are part of the DSCP field (as an example) the = technique is hybrid. In case the marking bits are dedicated and reserved = and are included in the protocol specification (e.g. BIER) marking = technique can be considered as passive. I suggest to add also hybrid in = the title. CMP: I agree with you overall. I believe a very small new subsection = within the Introduction, speaking to the categorization, as well as a = potential title update will address this comment.=20 CMP: And I would like to understand from IPPM whether setting or = clearing pre-allocated bits is really passive (since RFC 7799 says =E2=80=9C= MUST NOT change field values=E2=80=9D for Passive.) >=20 > B. Specific comments: >=20 > 1. Introduction >=20 > Nowadays, most of the traffic in Service Providers' networks carries > real time content. >=20 > CMP: While I do not dispute that statement, a citation would not hurt = to support the definitiveness of the very first sentence setting the = tone for the whole document. >=20 > [GF]: Agree, we can extend this statement. >=20 > CMP: Sections 2-4 look great. >=20 > CMP: I think there are issues in Section 5. Section 5 should cover the = following: >=20 > o Section 5 reports examples of implementation and deployment of = the > method. Furthermore the operational experiment done at Telecom > Italia is described; >=20 > CMP: And Section 5.1 is perfect and describes exactly the example of = implementation. However: >=20 > 5.3. Performance Measurement Marking Method in BIER Domain >=20 > CMP: The draft inherently describes a unicast service, not sure if = this document is not scoped to claim this sub-section. >=20 > [GF]: Here is an example on how to use this method as passive. >=20 > 5.4. Overlay OAM Passive Performance Measurement >=20 > The Overlay OAM Design Team is considering the preliminary OAM > requirements from NVO3, BIER, and SFC. Marking Method is the > preferred passive method to measure performance. >=20 > [I-D.ooamdt-rtgwg-ooam-requirement] and > [I-D.ooamdt-rtgwg-oam-gap-analysis] explain in deep this item. >=20 > CMP: This to me is a gross extrapolation. The text as written is = simply incorrect, and there=E2=80=99s no maturity or broad alignment to = include this I recommend removing this whole Section 5.4. > CMP: This is neither =E2=80=9Cexamples of implementation or = deployment=E2=80=9D. >=20 > [GF]: Yes, this is inherited by old versions of the document. It will = be deleted or rephrased. >=20 CMP: I would recommend deleting it as it appears old noise. Thanks, Carlos. >=20 > Net-net, I support this document but recommend these comments are = addressed. >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >=20 >=20 >> On May 30, 2017, at 11:53 AM, Brian Trammell (IETF) = wrote: >>=20 >> Greetings, IPPM, >>=20 >> As discussed in Chicago, this message begins a Working Group Last = Call on draft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) = Tuesday 20 June 2017. Please reply to ippm@ietf.org indicating whether = you believe this document is ready for publication, and if not, why not. >>=20 >> Many thanks, best regards, >>=20 >> Brian (as IPPM co-chair) >> _______________________________________________ >> 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 >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 >=20 > This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 >=20 > Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 = necessario. From nobody Wed Jun 7 11:36:29 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A303C129B4D; Wed, 7 Jun 2017 11:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BPjVdhTPZNgp; Wed, 7 Jun 2017 11:36:25 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66158129B3A; Wed, 7 Jun 2017 11:36:22 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id m4so1780660ioe.0; Wed, 07 Jun 2017 11:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2NnDsz48QnmB0msMx8rERfurzibHceE6HkT9ZnB3xhE=; b=hPOzyq/QzUtJ4nDKRur1nIcSS/b0LNQ1fqOd6LPOaZf5VQygPFoFnVbjCoy7vdJfQE wC6Zwi4W8wSZ/OkChVzl1PJAhKa/PDclJwE/i6QTZ70/Knu395Gs3FNTy9tIILWCXhvW 6bMs1wl66Vm8kxlV9VuS5dq4f9r+ks8LBqustX9gJ1LkRy/JtFG2AY7RFOIS9P+N2IVx IAKYq/kCZypaE9s0H3E65dt/vAhvBrRyxs98DruY2qNsJx0+5OSN8d6U3NbArT0o6ylb W1aFsBZiskLwUoTyNkpCJ5hx7lka5NAIQeIPn+zUdYtqIGtY/SOmuWTqapxAV69te5SI OwOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2NnDsz48QnmB0msMx8rERfurzibHceE6HkT9ZnB3xhE=; b=N6hiprNmNeguT7PmtF5Z5Vb0P0No/ddGTCrOnyy2jw+zRgwmKkpO5G1qbqJh1GnFdn Bd2JqIQH3Md9gMqhFS/Mg8H0PA0pDup/NBdYzOMipG8Ky3wa0OdRhKZ/4o7n7ecOWM/P dILyKj1jjej9CzBkCdTnBjFTQ0WQjrJEsm6Tsj9CZAfAJR4V7nqE6fsTlA0PeT08O/WG nRBCU2qjMIHL1ePd5OkoZQz6+BCtC1XmWyYtLEFXPDUzbSRA1w76kyUkgSY9DMajrVbH D1qR/LBIA8d+k9SqmkBpTFYMMTaFsg1zbLbDfyS/2URqYoRoH8MHB9lOUWWxfyGq7eD2 j+bg== X-Gm-Message-State: AODbwcCFZNAoM7/myANkngrE3+vNcSMPgcUxDeh6ktirhwz8UB+gh6bv RfpX3K/H+ZwUjWZmrXzL5w== X-Received: by 10.107.52.82 with SMTP id b79mr4128516ioa.213.1496860581482; Wed, 07 Jun 2017 11:36:21 -0700 (PDT) Received: from [10.0.0.10] ([117.193.186.117]) by smtp.gmail.com with ESMTPSA id w129sm1269949iow.20.2017.06.07.11.36.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 11:36:20 -0700 (PDT) From: Suresh Krishnan Message-Id: <52AB50CD-9412-4551-A8C8-461504D58041@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_89A8DC2F-0651-481F-9F58-A2C9CA9F58F6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 8 Jun 2017 00:06:14 +0530 In-Reply-To: <1071027365.4388609.1496781868310@mail.yahoo.com> Cc: The IESG , "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , Al Morton , "ippm@ietf.org" To: Nalini J Elkins References: <1081965272.4091641.1496769081453.ref@mail.yahoo.com> <1081965272.4091641.1496769081453@mail.yahoo.com> <1071027365.4388609.1496781868310@mail.yahoo.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ippm] draft-ietf-ippm-6man-pdm-option-11 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 18:36:27 -0000 --Apple-Mail=_89A8DC2F-0651-481F-9F58-A2C9CA9F58F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Nalini, > On Jun 7, 2017, at 2:14 AM, Nalini J Elkins = wrote: >=20 > Suresh, >=20 > > I looked over the new version and it has fixed 3 out of the 4 points = I brought up (Thanks!). The alignment one still remains unaddressed. I = thought we=20 > > agreed to an alignment requirement of 2n but the draft just says >=20 > > "The alignment for PDM is per RFC2460 [RFC2460]=E2=80=9D >=20 > > which really says nothing since RFC2460 expects *this* document to = state the alignment requirement. >=20 >=20 >=20 > I looked at a number of the other RFCs which define Destination = Options. RFC6275 : Mobility Support in IPv6, Section 6.2.1 has: >=20 > "Mobility options may have alignment requirements. Following the = convention in IPv6, these options are aligned in a packet so that = multi-octet values within the Option Data field of each option fall on = natural boundaries (i.e., fields of width n octets are placed at an = integer multiple of n octets from the start of the header, for n =3D 1, = 2, 4, or 8) [6]" >=20 >=20 > If we use the same wording: >=20 > OLD > ---- > "The alignment for PDM is per RFC2460 [RFC2460]=E2=80=9D >=20 > New > --- > "PDM has alignment requirements. Following the convention in IPv6, = these options are aligned in a packet so that multi-octet values within = the Option Data field of each option fall on natural boundaries (i.e., = fields of width n octets are placed at an integer multiple of n octets = from the start of the header, for n =3D 1, 2, 4, or 8) [RFC2460]"=20 >=20 >=20 > Please let me know if you are OK with the changes and I will create a = new version. Looks good to me. Thanks Suresh --Apple-Mail=_89A8DC2F-0651-481F-9F58-A2C9CA9F58F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Nalini,

On Jun 7, 2017, at 2:14 AM, = Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:

Suresh,

> I looked over = the new version and it has fixed 3 out of the 4 points I brought up = (Thanks!). The alignment one still remains unaddressed. I thought = we 
> agreed to an alignment requirement of 2n but = the draft just says

> "The alignment for = PDM is per RFC2460 [RFC2460]=E2=80=9D

> which really says = nothing since RFC2460 expects *this* document to state the alignment = requirement.


I looked at a number of the other RFCs which define = Destination Options.  RFC6275 : Mobility Support in IPv6, Section = 6.2.1 has:

"Mobility options may = have alignment requirements. Following the convention in IPv6, = these options are aligned in a packet so that multi-octet values within = the Option Data field of each option fall on natural boundaries (i.e., = fields of width n octets are placed at an integer multiple of n octets = from the start of the header, for n =3D 1, 2, 4, or 8) [6]"


If we use the same wording:

OLD
----
"The alignment for PDM is per RFC2460 = [RFC2460]=E2=80=9D

New
---
"PDM has alignment = requirements. Following the convention in IPv6, these options are = aligned in a packet so that multi-octet values within the Option Data = field of each option fall on natural boundaries (i.e., fields of width n = octets are placed at an integer multiple of n octets from the start of = the header, for n =3D 1, 2, 4, or 8) [RFC2460]" 


 Please let me know if you are OK with the changes and I = will create a new version.

Looks good to me.

Thanks
Suresh

= --Apple-Mail=_89A8DC2F-0651-481F-9F58-A2C9CA9F58F6-- From nobody Wed Jun 7 13:34:30 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88693129AC7 for ; Wed, 7 Jun 2017 13:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9cHKOzeLR5G9 for ; Wed, 7 Jun 2017 13:34:26 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4F1124BE8 for ; Wed, 7 Jun 2017 13:34:26 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id o65so10603456oif.1 for ; Wed, 07 Jun 2017 13:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2P/LYrEx6NO4AN5e/tUmL8da3pcdLujHtyipqb7G/DU=; b=eIA2WKPTsGKKrjSvOna9fXHLERwLdQs3jINn2h3MxI1+rtjtsYHrpbSsH6Tp2Iv7mo oYA7XEsU6y8NBWGBhoy2LpZONAbQDJDp6C5lrjz1ycDL5h07jXAI7xqu/c2nY56Nxlcs OL/6SMdCjwgO7H7ATrbjem19Jq/4kk+0ZBUC6SuehINK+PUup6QvQjAz8tQ4ST5N5ngr +QLEHBegEU4LP8lqzhebzZQslXncmyLjdGSLG0SRHdlJgl7d+9IwB2Ty7C2zddTGnvOh dvEj18NNvg7YlptB/QC7e/CTlxw7clxCFUVoG7Z8OGgIpiSoxUYBDkrlVwjn8XxaYCA7 eysA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2P/LYrEx6NO4AN5e/tUmL8da3pcdLujHtyipqb7G/DU=; b=sTXblZ79ligGgF3ssa0uK7ZQGkdb+gkWFoBm43hUAtyF4oDi7E89frFSGvnlVEjmyl AoMd6luFRh5HUkKYICwS3b59tfunLv3dUVgH4r2dKsHg+djHs2jQEDKDPsvCbsOn6i/B tGS3suLKbPkfBAP/G6/edqr8QZ68Bu9C1PZY7ZZ2bbrJ7gRCs5/x/qwZ0l6U2SzpA80I q+c1PyQ5akzP5+YHZrzidqgyeEhREFvX9BFREjBMsoC8dexYmtutGFfIenqqDk6bo7oT 8MU2qwDfKNpVOAvv7ER6bXpaXN3YlKGyovbebArRva5fJIYJS+poZOBfJeQAjCcPspq5 S2sg== X-Gm-Message-State: AODbwcC92O5C1SPNxbLbge/PUWw+yi9HJoSGzvUsDWnJEZrz8jWsOpgg EcZm3Ldyu2liqZ25erQpE0uq97fvjA== X-Received: by 10.202.104.99 with SMTP id d96mr10697822oic.61.1496867665322; Wed, 07 Jun 2017 13:34:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.225 with HTTP; Wed, 7 Jun 2017 13:34:24 -0700 (PDT) In-Reply-To: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> <8eae12d5997b4b50b774299b06f0c7c7@TELMBXB02RM001.telecomitalia.local> From: Greg Mirsky Date: Wed, 7 Jun 2017 13:34:24 -0700 Message-ID: To: Carlos Pignataro Cc: Fioccola Giuseppe , IETF IPPM WG Content-Type: multipart/alternative; boundary="001a1140f8e277a9fd055164a91b" Archived-At: Subject: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 20:34:29 -0000 --001a1140f8e277a9fd055164a91b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, RFC 7799 acknowledges that with proper instrumentation methods that modify data packets may produce measurement results as passive measurement methods= : There may be circumstances where results measured with Hybrid Methods can be considered equivalent to those measured with Passive Methods. In that sense the Alternate Marking method may be applied so that is behaves and produces results as passive measurement method. Regards, Greg On Wed, Jun 7, 2017 at 9:52 AM, Carlos Pignataro wrote= : > Ciao, Giuseppe, > > Happy to support this document. > > I agree with all your responses. Please find a couple followups inline. > > > On Jun 7, 2017, at 12:11 PM, Fioccola Giuseppe telecomitalia.it> wrote: > > > > Thanks for the support, Carlos. > > Answers to your comments are inline tagged as [GF]. > > > > Giuseppe > > > > -----Messaggio originale----- > > Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Carlos Pignataro > (cpignata) > > Inviato: marted=C3=AC 6 giugno 2017 19:03 > > A: Brian Trammell (IETF) > > Cc: IETF IPPM WG > > Oggetto: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark > > > > Brian, > > > > I support advancing this document and believe it=E2=80=99s ready to be = sent to > the IESG. > > > > This is an important document and foundation to specific protocol > realizations, and its quality is very good. I also believe that > Experimental, as currently intended, is appropriate. > > > > I do have a set of comments, for consideration as part of this WGLC. > > > > While the method itself is described in great detail and with care, som= e > contextual information and text around justifications or potential future > implementation is a bit more loose. > > > > Comments: > > > > A. Title and method > > > > The title of this document is =E2=80=9CAlternate Marking method for pas= sive > performance monitoring=E2=80=9D. > > > > However, as Greg Mirsky repeatedly mentioned in different contexts, > let=E2=80=99s use IETF definitions or active/passive/inband/etc. As such,= Passive > monitoring does not modify packets. > > > > Based on the definition at RFC 7799 (which is not referenced): > > > > https://tools.ietf.org/html/rfc7799#section-3.6 > > 3.6. Passive Methods > > > > Passive Methods of Measurement are: > > > > o based solely on observations of an undisturbed and unmodified > > packet stream of interest (in other words, the method of > > measurement MUST NOT add, change, or remove packets or fields or > > change field values anywhere along the path). > > > > Saying =E2=80=9Cmarking for passive=E2=80=9D is, based on this definiti= on, an oxymoron. > Marking / coloring would go against the definition of passive. > > > > [GF]: Agree, this is an important point we should clarify together with > IPPM. A reference to RFC7799 can be added. In my opinion, marking method > could be considered hybrid or passive depending on the case. In case the > marking bits are part of the DSCP field (as an example) the technique is > hybrid. In case the marking bits are dedicated and reserved and are > included in the protocol specification (e.g. BIER) marking technique can = be > considered as passive. I suggest to add also hybrid in the title. > > CMP: I agree with you overall. I believe a very small new subsection > within the Introduction, speaking to the categorization, as well as a > potential title update will address this comment. > > CMP: And I would like to understand from IPPM whether setting or clearing > pre-allocated bits is really passive (since RFC 7799 says =E2=80=9C MUST = NOT change > field values=E2=80=9D for Passive.) > > > > > B. Specific comments: > > > > 1. Introduction > > > > Nowadays, most of the traffic in Service Providers' networks carries > > real time content. > > > > CMP: While I do not dispute that statement, a citation would not hurt t= o > support the definitiveness of the very first sentence setting the tone fo= r > the whole document. > > > > [GF]: Agree, we can extend this statement. > > > > CMP: Sections 2-4 look great. > > > > CMP: I think there are issues in Section 5. Section 5 should cover the > following: > > > > o Section 5 reports examples of implementation and deployment of the > > method. Furthermore the operational experiment done at Telecom > > Italia is described; > > > > CMP: And Section 5.1 is perfect and describes exactly the example of > implementation. However: > > > > 5.3. Performance Measurement Marking Method in BIER Domain > > > > CMP: The draft inherently describes a unicast service, not sure if this > document is not scoped to claim this sub-section. > > > > [GF]: Here is an example on how to use this method as passive. > > > > 5.4. Overlay OAM Passive Performance Measurement > > > > The Overlay OAM Design Team is considering the preliminary OAM > > requirements from NVO3, BIER, and SFC. Marking Method is the > > preferred passive method to measure performance. > > > > [I-D.ooamdt-rtgwg-ooam-requirement] and > > [I-D.ooamdt-rtgwg-oam-gap-analysis] explain in deep this item. > > > > CMP: This to me is a gross extrapolation. The text as written is simply > incorrect, and there=E2=80=99s no maturity or broad alignment to include = this I > recommend removing this whole Section 5.4. > > CMP: This is neither =E2=80=9Cexamples of implementation or deployment= =E2=80=9D. > > > > [GF]: Yes, this is inherited by old versions of the document. It will b= e > deleted or rephrased. > > > > CMP: I would recommend deleting it as it appears old noise. > > Thanks, > > Carlos. > > > > > Net-net, I support this document but recommend these comments are > addressed. > > > > Thanks, > > > > =E2=80=94 Carlos. > > > > > > > >> On May 30, 2017, at 11:53 AM, Brian Trammell (IETF) > wrote: > >> > >> Greetings, IPPM, > >> > >> As discussed in Chicago, this message begins a Working Group Last Call > on draft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday 2= 0 > June 2017. Please reply to ippm@ietf.org indicating whether you believe > this document is ready for publication, and if not, why not. > >> > >> Many thanks, best regards, > >> > >> Brian (as IPPM co-chair) > >> _______________________________________________ > >> 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 > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > > > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments an= d > advise the sender by return e-mail, Thanks. > > > > Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 necessario. > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --001a1140f8e277a9fd055164a91b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,
RFC 7799 acknowledges that with proper inst= rumentation methods that modify data packets may produce measurement result= s as passive measurement methods:
   There may be circumstances where results measured with Hybrid Methods
   can be considered equivalent to those measured with Passive Methods.
In that sense the Alternate Marking method may be applied = so that is behaves and produces results as passive measurement method.

Regards,
Greg

On Wed, Jun 7, 2017 at 9:52 AM, Carl= os Pignataro <cpignata@cisco.com> wrote:
Ciao, Giuseppe,

Happy to support this document.

I agree with all your responses. Please find a couple followups inline.

> On Jun 7, 2017, at 12:11 PM, Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it<= /a>> wrote:
>
> Thanks for the support, Carlos.
> Answers to your comments are inline tagged as [GF].
>
> Giuseppe
>
> -----Messaggio originale-----
> Da: ippm [mailto:ippm-bounces= @ietf.org] Per conto di Carlos Pignataro (cpignata)
> Inviato: marted=C3=AC 6 giugno 2017 19:03
> A: Brian Trammell (IETF)
> Cc: IETF IPPM WG
> Oggetto: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark
>
> Brian,
>
> I support advancing this document and believe it=E2=80=99s ready to be= sent to the IESG.
>
> This is an important document and foundation to specific protocol real= izations, and its quality is very good. I also believe that Experimental, a= s currently intended, is appropriate.
>
> I do have a set of comments, for consideration as part of this WGLC. >
> While the method itself is described in great detail and with care, so= me contextual information and text around justifications or potential futur= e implementation is a bit more loose.
>
> Comments:
>
> A. Title and method
>
> The title of this document is =E2=80=9CAlternate Marking method for pa= ssive performance monitoring=E2=80=9D.
>
> However, as Greg Mirsky repeatedly mentioned in different contexts, le= t=E2=80=99s use IETF definitions or active/passive/inband/etc. As such, Pas= sive monitoring does not modify packets.
>
> Based on the definition at RFC 7799 (which is not referenced):
>
> https://tools.ietf.org/html/rfc7799#section= -3.6
> 3.6.=C2=A0 Passive Methods
>
>=C2=A0 =C2=A0Passive Methods of Measurement are:
>
>=C2=A0 =C2=A0o=C2=A0 based solely on observations of an undisturbed and= unmodified
>=C2=A0 =C2=A0 =C2=A0 packet stream of interest (in other words, the met= hod of
>=C2=A0 =C2=A0 =C2=A0 measurement MUST NOT add, change, or remove packet= s or fields or
>=C2=A0 =C2=A0 =C2=A0 change field values anywhere along the path).
>
> Saying =E2=80=9Cmarking for passive=E2=80=9D is, based on this definit= ion, an oxymoron. Marking / coloring would go against the definition of pas= sive.
>
> [GF]: Agree, this is an important point we should clarify together wit= h IPPM. A reference to RFC7799 can be added. In my opinion, marking method = could be considered hybrid or passive depending on the case. In case the ma= rking bits are part of the DSCP field (as an example) the technique is hybr= id. In case the marking bits are dedicated and reserved and are included in= the protocol specification (e.g. BIER) marking technique can be considered= as passive. I suggest to add also hybrid in the title.

CMP: I agree with you overall. I believe a very small new subse= ction within the Introduction, speaking to the categorization, as well as a= potential title update will address this comment.

CMP: And I would like to understand from IPPM whether setting or clearing p= re-allocated bits is really passive (since RFC 7799 says =E2=80=9C MUST NOT= change field values=E2=80=9D for Passive.)

>
> B. Specific comments:
>
> 1.=C2=A0 Introduction
>
>=C2=A0 =C2=A0Nowadays, most of the traffic in Service Providers' ne= tworks carries
>=C2=A0 =C2=A0real time content.
>
> CMP: While I do not dispute that statement, a citation would not hurt = to support the definitiveness of the very first sentence setting the tone f= or the whole document.
>
> [GF]: Agree, we can extend this statement.
>
> CMP: Sections 2-4 look great.
>
> CMP: I think there are issues in Section 5. Section 5 should cover the= following:
>
>=C2=A0 =C2=A0o=C2=A0 Section 5 reports examples of implementation and d= eployment of the
>=C2=A0 =C2=A0 =C2=A0 method.=C2=A0 Furthermore the operational experime= nt done at Telecom
>=C2=A0 =C2=A0 =C2=A0 Italia is described;
>
> CMP: And Section 5.1 is perfect and describes exactly the example of i= mplementation. However:
>
> 5.3.=C2=A0 Performance Measurement Marking Method in BIER Domain
>
> CMP: The draft inherently describes a unicast service, not sure if thi= s document is not scoped to claim this sub-section.
>
> [GF]: Here is an example on how to use this method as passive.
>
> 5.4.=C2=A0 Overlay OAM Passive Performance Measurement
>
>=C2=A0 =C2=A0The Overlay OAM Design Team is considering the preliminary= OAM
>=C2=A0 =C2=A0requirements from NVO3, BIER, and SFC.=C2=A0 Marking Metho= d is the
>=C2=A0 =C2=A0preferred passive method to measure performance.
>
>=C2=A0 =C2=A0[I-D.ooamdt-rtgwg-ooam-requirement] and
>=C2=A0 =C2=A0[I-D.ooamdt-rtgwg-oam-gap-analysis] explain in deep t= his item.
>
> CMP: This to me is a gross extrapolation. The text as written is simpl= y incorrect, and there=E2=80=99s no maturity or broad alignment to include = this I recommend removing this whole Section 5.4.
> CMP: This is neither =E2=80=9Cexamples of implementation or deployment= =E2=80=9D.
>
> [GF]: Yes, this is inherited by old versions of the document. It will = be deleted or rephrased.
>

CMP: I would recommend deleting it as it appears old noise.

Thanks,

Carlos.

>
> Net-net, I support this document but recommend these comments are addr= essed.
>
> Thanks,
>
> =E2=80=94 Carlos.
>
>
>
>> On May 30, 2017, at 11:53 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>>
>> Greetings, IPPM,
>>
>> As discussed in Chicago, this message begins a Working Group Last = Call on draft-ietf-ippm-alt-mark, to=C2=A0 to run until EOB CEST (UTC +2) T= uesday 20 June 2017. Please reply to ippm@= ietf.org indicating whether you believe this document is ready for publ= ication, and if not, why not.
>>
>> Many thanks, best regards,
>>
>> Brian (as IPPM co-chair)
>> _______________________________________________
>> 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 >
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e persone indicate. La diffusione, copia o qualsiasi altra azione derivante= dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualor= a abbiate ricevuto questo documento per errore siete cortesemente pregati d= i darne immediata comunicazione al mittente e di provvedere alla sua distru= zione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privil= eged information intended for the addressee(s) only. Dissemination, copying= , printing or use by anybody else is unauthorised. If you are not the inten= ded recipient, please delete this message and any attachments and advise th= e sender by return e-mail, Thanks.
>
> Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 necess= ario.

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

--001a1140f8e277a9fd055164a91b-- From nobody Wed Jun 7 14:02:38 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A04F1294CE for ; Wed, 7 Jun 2017 14:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 0IIT3VC6vAUi for ; Wed, 7 Jun 2017 14:02:33 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807DE124BE8 for ; Wed, 7 Jun 2017 14:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31306; q=dns/txt; s=iport; t=1496869353; x=1498078953; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bLDXtvdkvAb5b9tUEoNC02SyUbEaXSXrb8qa9cME20c=; b=I5NI7vwKOyYqVVg/QU+QiwSKDZo4T7oSRyeBpAOdv0jQuCANCtYKsTWx HUJXHKofRfgCpT7czgtUFKeDug0621zCl9ILh09xaB93K8NsXnAPT/F2F bPFGB2o8JY/I+/87amqlVOewr+x4UqVMF3Lo4Wt/elIqnUr3IiNP+wJnf s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAAAeaThZ/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9pYoENB4NsihiRaYgqjVaCECEBCoV4AhqCWz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECAQEBIUQHCwULAgEIGCcDAgICHwYLFBECBA4FhhSDM0wDDQgQr?= =?us-ascii?q?wWCJodADYQyAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWEUIIRaHgrgWmBDIJYgXU?= =?us-ascii?q?BAYMtMIIxBZcHhmQTOwKHJIc1hF2CBoU+ijyJD4IziSQBHziBCnQVHCoSAYQ7g?= =?us-ascii?q?jp2AYdBDxeBDIENAQEB?= X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208,217";a="437220714" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jun 2017 21:02:31 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v57L2VHF001619 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Jun 2017 21:02:31 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Jun 2017 17:02:30 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 7 Jun 2017 17:02:30 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: Fioccola Giuseppe , IETF IPPM WG Thread-Topic: [ippm] WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2VzoGahGlx1gOUq0eoSBLxU0T6IYXdoAgAGD9gCAAAtcAIAAPg4AgAAH2gA= Date: Wed, 7 Jun 2017 21:02:30 +0000 Message-ID: <8F0D52B3-D9D8-40A4-B51A-474FF95EE38A@cisco.com> References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> <8eae12d5997b4b50b774299b06f0c7c7@TELMBXB02RM001.telecomitalia.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.131] Content-Type: multipart/alternative; boundary="_000_8F0D52B3D9D840A4B51A474FF95EE38Aciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 21:02:36 -0000 --_000_8F0D52B3D9D840A4B51A474FF95EE38Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KVGhhbmsgeW91IGZvciB0aGUgZm9sbG93LXVwLg0KDQpXaGF0IHlvdSB3cml0ZSBp cyB2ZXJ5IGludGVyZXN0aW5nIGJ1dCBpcnJlbGV2YW50IGFuZCBvcnRob2dvbmFsIHRvIG15IGNv bW1lbnQuIEkgYW0gbm90IGNvbW1lbnRpbmcgb24gZXF1aXZhbGVuY3kgb2YgcmVzdWx0cy4gSSBh bSBjb21tZW50aW5nIG9uIG5hbWluZyBhbmQgZGVmaW5pdGlvbiBvZiB0ZXJtcy4gSSB0aGluayBH aXVzZXBwZeKAmXMgcmVzcG9uc2Ugd2FzIG1vcmUgdXNlZnVsOg0KPiBbR0ZdOiBBZ3JlZSwgdGhp cyBpcyBhbiBpbXBvcnRhbnQgcG9pbnQgd2Ugc2hvdWxkIGNsYXJpZnkgdG9nZXRoZXIgd2l0aCBJ UFBNLg0KDQpUaGFuayB5b3UgZm9yIGluaXRpYWxseSBwb2ludGluZyB0byB0aGUgZGVmaW5pdGlv bnMgaW4gUkZDIDc3OTkuIEluZGVlZCwgdW5kZXIgc29tZSBjaXJjdW1zdGFuY2VzLCBwYXNzaXZl IGFuZCBoeWJyaWQgY2FuIHByb2R1Y2UgZXF1aXZhbGVudCByZXN1bHRzLg0KSG93ZXZlciwgdW5k ZXIgYWxsIGNpcmN1bXN0YW5jZXMsIGh5YnJpZCAqaXMqIGh5YnJpZCwgYW5kIHBhc3NpdmUgaXMs IHdlbGwsIHBhc3NpdmUuDQoNClllcywgcmVzdWx0cyBjYW4gYmUgY29uc2lkZXJlZCBlcXVpdmFs ZW50ICh1bmRlciBzb21lIGNpcmN1bXN0YW5jZXMpLiBObywgd2UgY2Fubm90IHJlbmFtZSB0aGlu Z3MuIE5vLCBlcXVpdmFsZW50IHJlc3VsdHMgZG9lcyBub3QgbWVhbiByZS1jYXRlZ29yaXphdGlv bi4NCg0KR2l2ZW4gdGhlIGZhY3QgdGhhdCB0aGVyZSBhcmUgb3BlbiBxdWVzdGlvbnMgKHN1Y2gg YXMsIHdoYXQgaGFwcGVucyBmcm9tIGEgZGVmaW5pdGlvbiBwZXJzcGVjdGl2ZSBpZiB0aGVyZSBp cyBNYXJraW5nIGZvciBmaWVsZHMgdGhhdCBhcmUgYWN0dWFsbHkgcmVzZXJ2ZWQgZm9yIHRoaXMg ZnVuY3Rpb25hbGl0eSBhcyBvcHBvc2VkIHRvIG92ZXJsb2FkaW5nIGZpZWxkcyksIEkgcmVjb21t ZW5kIGEgc21hbGwgc3Vic2VjdGlvbiBvZiB0aGUgSW50cm8gZXhwbGFpbmluZyB0aGUgcHJvcGVy IGNhdGVnb3JpemF0aW9uLg0KDQpBbmQgZ2l2ZW4gdGhlIGZhY3QgdGhhdCB0aGUgZmlyc3QgYnVs bGV0IGluIHRoZSBkZWZpbml0aW9uIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3 Nzk5I3NlY3Rpb24tMy42IGluY2x1ZGVzICJ1bmRpc3R1cmJlZCBhbmQgdW5tb2RpZmllZOKAnSBh bmQgIk1VU1QgTk9UIFvigKZdIGNoYW5nZSBmaWVsZCB2YWx1ZXPigJ0gd2hpY2ggaXMgcXVpdGUg dW5lcXVpdm9jYWwgb2YgYSBzdGF0ZW1lbnQuDQoNCkJlc3QsDQoNCuKAlCBDYXJsb3MuDQoNCk9u IEp1biA3LCAyMDE3LCBhdCA0OjM0IFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwu Y29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGkgQ2FybG9zLA0K UkZDIDc3OTkgYWNrbm93bGVkZ2VzIHRoYXQgd2l0aCBwcm9wZXIgaW5zdHJ1bWVudGF0aW9uIG1l dGhvZHMgdGhhdCBtb2RpZnkgZGF0YSBwYWNrZXRzIG1heSBwcm9kdWNlIG1lYXN1cmVtZW50IHJl c3VsdHMgYXMgcGFzc2l2ZSBtZWFzdXJlbWVudCBtZXRob2RzOg0KDQogICBUaGVyZSBtYXkgYmUg Y2lyY3Vtc3RhbmNlcyB3aGVyZSByZXN1bHRzIG1lYXN1cmVkIHdpdGggSHlicmlkIE1ldGhvZHMN CiAgIGNhbiBiZSBjb25zaWRlcmVkIGVxdWl2YWxlbnQgdG8gdGhvc2UgbWVhc3VyZWQgd2l0aCBQ YXNzaXZlIE1ldGhvZHMuDQoNCg0KSW4gdGhhdCBzZW5zZSB0aGUgQWx0ZXJuYXRlIE1hcmtpbmcg bWV0aG9kIG1heSBiZSBhcHBsaWVkIHNvIHRoYXQgaXMgYmVoYXZlcyBhbmQgcHJvZHVjZXMgcmVz dWx0cyBhcyBwYXNzaXZlIG1lYXN1cmVtZW50IG1ldGhvZC4NCg0KUmVnYXJkcywNCkdyZWcNCg0K T24gV2VkLCBKdW4gNywgMjAxNyBhdCA5OjUyIEFNLCBDYXJsb3MgUGlnbmF0YXJvIDxjcGlnbmF0 YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3RlOg0KQ2lhbywgR2l1 c2VwcGUsDQoNCkhhcHB5IHRvIHN1cHBvcnQgdGhpcyBkb2N1bWVudC4NCg0KSSBhZ3JlZSB3aXRo IGFsbCB5b3VyIHJlc3BvbnNlcy4gUGxlYXNlIGZpbmQgYSBjb3VwbGUgZm9sbG93dXBzIGlubGlu ZS4NCg0KPiBPbiBKdW4gNywgMjAxNywgYXQgMTI6MTEgUE0sIEZpb2Njb2xhIEdpdXNlcHBlIDxn aXVzZXBwZS5maW9jY29sYUB0ZWxlY29taXRhbGlhLml0PG1haWx0bzpnaXVzZXBwZS5maW9jY29s YUB0ZWxlY29taXRhbGlhLml0Pj4gd3JvdGU6DQo+DQo+IFRoYW5rcyBmb3IgdGhlIHN1cHBvcnQs IENhcmxvcy4NCj4gQW5zd2VycyB0byB5b3VyIGNvbW1lbnRzIGFyZSBpbmxpbmUgdGFnZ2VkIGFz IFtHRl0uDQo+DQo+IEdpdXNlcHBlDQo+DQo+IC0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0t DQo+IERhOiBpcHBtIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppcHBtLWJv dW5jZXNAaWV0Zi5vcmc+XSBQZXIgY29udG8gZGkgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEp DQo+IEludmlhdG86IG1hcnRlZMOsIDYgZ2l1Z25vIDIwMTcgMTk6MDMNCj4gQTogQnJpYW4gVHJh bW1lbGwgKElFVEYpDQo+IENjOiBJRVRGIElQUE0gV0cNCj4gT2dnZXR0bzogUmU6IFtpcHBtXSBX R0xDIG9uIGRyYWZ0LWlldGYtaXBwbS1hbHQtbWFyaw0KPg0KPiBCcmlhbiwNCj4NCj4gSSBzdXBw b3J0IGFkdmFuY2luZyB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZlIGl04oCZcyByZWFkeSB0byBi ZSBzZW50IHRvIHRoZSBJRVNHLg0KPg0KPiBUaGlzIGlzIGFuIGltcG9ydGFudCBkb2N1bWVudCBh bmQgZm91bmRhdGlvbiB0byBzcGVjaWZpYyBwcm90b2NvbCByZWFsaXphdGlvbnMsIGFuZCBpdHMg cXVhbGl0eSBpcyB2ZXJ5IGdvb2QuIEkgYWxzbyBiZWxpZXZlIHRoYXQgRXhwZXJpbWVudGFsLCBh cyBjdXJyZW50bHkgaW50ZW5kZWQsIGlzIGFwcHJvcHJpYXRlLg0KPg0KPiBJIGRvIGhhdmUgYSBz ZXQgb2YgY29tbWVudHMsIGZvciBjb25zaWRlcmF0aW9uIGFzIHBhcnQgb2YgdGhpcyBXR0xDLg0K Pg0KPiBXaGlsZSB0aGUgbWV0aG9kIGl0c2VsZiBpcyBkZXNjcmliZWQgaW4gZ3JlYXQgZGV0YWls IGFuZCB3aXRoIGNhcmUsIHNvbWUgY29udGV4dHVhbCBpbmZvcm1hdGlvbiBhbmQgdGV4dCBhcm91 bmQganVzdGlmaWNhdGlvbnMgb3IgcG90ZW50aWFsIGZ1dHVyZSBpbXBsZW1lbnRhdGlvbiBpcyBh IGJpdCBtb3JlIGxvb3NlLg0KPg0KPiBDb21tZW50czoNCj4NCj4gQS4gVGl0bGUgYW5kIG1ldGhv ZA0KPg0KPiBUaGUgdGl0bGUgb2YgdGhpcyBkb2N1bWVudCBpcyDigJxBbHRlcm5hdGUgTWFya2lu ZyBtZXRob2QgZm9yIHBhc3NpdmUgcGVyZm9ybWFuY2UgbW9uaXRvcmluZ+KAnS4NCj4NCj4gSG93 ZXZlciwgYXMgR3JlZyBNaXJza3kgcmVwZWF0ZWRseSBtZW50aW9uZWQgaW4gZGlmZmVyZW50IGNv bnRleHRzLCBsZXTigJlzIHVzZSBJRVRGIGRlZmluaXRpb25zIG9yIGFjdGl2ZS9wYXNzaXZlL2lu YmFuZC9ldGMuIEFzIHN1Y2gsIFBhc3NpdmUgbW9uaXRvcmluZyBkb2VzIG5vdCBtb2RpZnkgcGFj a2V0cy4NCj4NCj4gQmFzZWQgb24gdGhlIGRlZmluaXRpb24gYXQgUkZDIDc3OTkgKHdoaWNoIGlz IG5vdCByZWZlcmVuY2VkKToNCj4NCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc3 OTkjc2VjdGlvbi0zLjYNCj4gMy42LiAgUGFzc2l2ZSBNZXRob2RzDQo+DQo+ICAgUGFzc2l2ZSBN ZXRob2RzIG9mIE1lYXN1cmVtZW50IGFyZToNCj4NCj4gICBvICBiYXNlZCBzb2xlbHkgb24gb2Jz ZXJ2YXRpb25zIG9mIGFuIHVuZGlzdHVyYmVkIGFuZCB1bm1vZGlmaWVkDQo+ICAgICAgcGFja2V0 IHN0cmVhbSBvZiBpbnRlcmVzdCAoaW4gb3RoZXIgd29yZHMsIHRoZSBtZXRob2Qgb2YNCj4gICAg ICBtZWFzdXJlbWVudCBNVVNUIE5PVCBhZGQsIGNoYW5nZSwgb3IgcmVtb3ZlIHBhY2tldHMgb3Ig ZmllbGRzIG9yDQo+ICAgICAgY2hhbmdlIGZpZWxkIHZhbHVlcyBhbnl3aGVyZSBhbG9uZyB0aGUg cGF0aCkuDQo+DQo+IFNheWluZyDigJxtYXJraW5nIGZvciBwYXNzaXZl4oCdIGlzLCBiYXNlZCBv biB0aGlzIGRlZmluaXRpb24sIGFuIG94eW1vcm9uLiBNYXJraW5nIC8gY29sb3Jpbmcgd291bGQg Z28gYWdhaW5zdCB0aGUgZGVmaW5pdGlvbiBvZiBwYXNzaXZlLg0KPg0KPiBbR0ZdOiBBZ3JlZSwg dGhpcyBpcyBhbiBpbXBvcnRhbnQgcG9pbnQgd2Ugc2hvdWxkIGNsYXJpZnkgdG9nZXRoZXIgd2l0 aCBJUFBNLiBBIHJlZmVyZW5jZSB0byBSRkM3Nzk5IGNhbiBiZSBhZGRlZC4gSW4gbXkgb3Bpbmlv biwgbWFya2luZyBtZXRob2QgY291bGQgYmUgY29uc2lkZXJlZCBoeWJyaWQgb3IgcGFzc2l2ZSBk ZXBlbmRpbmcgb24gdGhlIGNhc2UuIEluIGNhc2UgdGhlIG1hcmtpbmcgYml0cyBhcmUgcGFydCBv ZiB0aGUgRFNDUCBmaWVsZCAoYXMgYW4gZXhhbXBsZSkgdGhlIHRlY2huaXF1ZSBpcyBoeWJyaWQu IEluIGNhc2UgdGhlIG1hcmtpbmcgYml0cyBhcmUgZGVkaWNhdGVkIGFuZCByZXNlcnZlZCBhbmQg YXJlIGluY2x1ZGVkIGluIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIChlLmcuIEJJRVIpIG1h cmtpbmcgdGVjaG5pcXVlIGNhbiBiZSBjb25zaWRlcmVkIGFzIHBhc3NpdmUuIEkgc3VnZ2VzdCB0 byBhZGQgYWxzbyBoeWJyaWQgaW4gdGhlIHRpdGxlLg0KDQpDTVA6IEkgYWdyZWUgd2l0aCB5b3Ug b3ZlcmFsbC4gSSBiZWxpZXZlIGEgdmVyeSBzbWFsbCBuZXcgc3Vic2VjdGlvbiB3aXRoaW4gdGhl IEludHJvZHVjdGlvbiwgc3BlYWtpbmcgdG8gdGhlIGNhdGVnb3JpemF0aW9uLCBhcyB3ZWxsIGFz IGEgcG90ZW50aWFsIHRpdGxlIHVwZGF0ZSB3aWxsIGFkZHJlc3MgdGhpcyBjb21tZW50Lg0KDQpD TVA6IEFuZCBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCBmcm9tIElQUE0gd2hldGhlciBzZXR0 aW5nIG9yIGNsZWFyaW5nIHByZS1hbGxvY2F0ZWQgYml0cyBpcyByZWFsbHkgcGFzc2l2ZSAoc2lu Y2UgUkZDIDc3OTkgc2F5cyDigJwgTVVTVCBOT1QgY2hhbmdlIGZpZWxkIHZhbHVlc+KAnSBmb3Ig UGFzc2l2ZS4pDQoNCj4NCj4gQi4gU3BlY2lmaWMgY29tbWVudHM6DQo+DQo+IDEuICBJbnRyb2R1 Y3Rpb24NCj4NCj4gICBOb3dhZGF5cywgbW9zdCBvZiB0aGUgdHJhZmZpYyBpbiBTZXJ2aWNlIFBy b3ZpZGVycycgbmV0d29ya3MgY2Fycmllcw0KPiAgIHJlYWwgdGltZSBjb250ZW50Lg0KPg0KPiBD TVA6IFdoaWxlIEkgZG8gbm90IGRpc3B1dGUgdGhhdCBzdGF0ZW1lbnQsIGEgY2l0YXRpb24gd291 bGQgbm90IGh1cnQgdG8gc3VwcG9ydCB0aGUgZGVmaW5pdGl2ZW5lc3Mgb2YgdGhlIHZlcnkgZmly c3Qgc2VudGVuY2Ugc2V0dGluZyB0aGUgdG9uZSBmb3IgdGhlIHdob2xlIGRvY3VtZW50Lg0KPg0K PiBbR0ZdOiBBZ3JlZSwgd2UgY2FuIGV4dGVuZCB0aGlzIHN0YXRlbWVudC4NCj4NCj4gQ01QOiBT ZWN0aW9ucyAyLTQgbG9vayBncmVhdC4NCj4NCj4gQ01QOiBJIHRoaW5rIHRoZXJlIGFyZSBpc3N1 ZXMgaW4gU2VjdGlvbiA1LiBTZWN0aW9uIDUgc2hvdWxkIGNvdmVyIHRoZSBmb2xsb3dpbmc6DQo+ DQo+ICAgbyAgU2VjdGlvbiA1IHJlcG9ydHMgZXhhbXBsZXMgb2YgaW1wbGVtZW50YXRpb24gYW5k IGRlcGxveW1lbnQgb2YgdGhlDQo+ICAgICAgbWV0aG9kLiAgRnVydGhlcm1vcmUgdGhlIG9wZXJh dGlvbmFsIGV4cGVyaW1lbnQgZG9uZSBhdCBUZWxlY29tDQo+ICAgICAgSXRhbGlhIGlzIGRlc2Ny aWJlZDsNCj4NCj4gQ01QOiBBbmQgU2VjdGlvbiA1LjEgaXMgcGVyZmVjdCBhbmQgZGVzY3JpYmVz IGV4YWN0bHkgdGhlIGV4YW1wbGUgb2YgaW1wbGVtZW50YXRpb24uIEhvd2V2ZXI6DQo+DQo+IDUu My4gIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IE1hcmtpbmcgTWV0aG9kIGluIEJJRVIgRG9tYWlu DQo+DQo+IENNUDogVGhlIGRyYWZ0IGluaGVyZW50bHkgZGVzY3JpYmVzIGEgdW5pY2FzdCBzZXJ2 aWNlLCBub3Qgc3VyZSBpZiB0aGlzIGRvY3VtZW50IGlzIG5vdCBzY29wZWQgdG8gY2xhaW0gdGhp cyBzdWItc2VjdGlvbi4NCj4NCj4gW0dGXTogSGVyZSBpcyBhbiBleGFtcGxlIG9uIGhvdyB0byB1 c2UgdGhpcyBtZXRob2QgYXMgcGFzc2l2ZS4NCj4NCj4gNS40LiAgT3ZlcmxheSBPQU0gUGFzc2l2 ZSBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudA0KPg0KPiAgIFRoZSBPdmVybGF5IE9BTSBEZXNpZ24g VGVhbSBpcyBjb25zaWRlcmluZyB0aGUgcHJlbGltaW5hcnkgT0FNDQo+ICAgcmVxdWlyZW1lbnRz IGZyb20gTlZPMywgQklFUiwgYW5kIFNGQy4gIE1hcmtpbmcgTWV0aG9kIGlzIHRoZQ0KPiAgIHBy ZWZlcnJlZCBwYXNzaXZlIG1ldGhvZCB0byBtZWFzdXJlIHBlcmZvcm1hbmNlLg0KPg0KPiAgIFtJ LUQub29hbWR0LXJ0Z3dnLW9vYW0tcmVxdWlyZW1lbnRdIGFuZA0KPiAgIFtJLUQub29hbWR0LXJ0 Z3dnLW9hbS1nYXAtYW5hbHlzaXNdIGV4cGxhaW4gaW4gZGVlcCB0aGlzIGl0ZW0uDQo+DQo+IENN UDogVGhpcyB0byBtZSBpcyBhIGdyb3NzIGV4dHJhcG9sYXRpb24uIFRoZSB0ZXh0IGFzIHdyaXR0 ZW4gaXMgc2ltcGx5IGluY29ycmVjdCwgYW5kIHRoZXJl4oCZcyBubyBtYXR1cml0eSBvciBicm9h ZCBhbGlnbm1lbnQgdG8gaW5jbHVkZSB0aGlzIEkgcmVjb21tZW5kIHJlbW92aW5nIHRoaXMgd2hv bGUgU2VjdGlvbiA1LjQuDQo+IENNUDogVGhpcyBpcyBuZWl0aGVyIOKAnGV4YW1wbGVzIG9mIGlt cGxlbWVudGF0aW9uIG9yIGRlcGxveW1lbnTigJ0uDQo+DQo+IFtHRl06IFllcywgdGhpcyBpcyBp bmhlcml0ZWQgYnkgb2xkIHZlcnNpb25zIG9mIHRoZSBkb2N1bWVudC4gSXQgd2lsbCBiZSBkZWxl dGVkIG9yIHJlcGhyYXNlZC4NCj4NCg0KQ01QOiBJIHdvdWxkIHJlY29tbWVuZCBkZWxldGluZyBp dCBhcyBpdCBhcHBlYXJzIG9sZCBub2lzZS4NCg0KVGhhbmtzLA0KDQpDYXJsb3MuDQoNCj4NCj4g TmV0LW5ldCwgSSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQgYnV0IHJlY29tbWVuZCB0aGVzZSBjb21t ZW50cyBhcmUgYWRkcmVzc2VkLg0KPg0KPiBUaGFua3MsDQo+DQo+IOKAlCBDYXJsb3MuDQo+DQo+ DQo+DQo+PiBPbiBNYXkgMzAsIDIwMTcsIGF0IDExOjUzIEFNLCBCcmlhbiBUcmFtbWVsbCAoSUVU RikgPGlldGZAdHJhbW1lbGwuY2g8bWFpbHRvOmlldGZAdHJhbW1lbGwuY2g+PiB3cm90ZToNCj4+ DQo+PiBHcmVldGluZ3MsIElQUE0sDQo+Pg0KPj4gQXMgZGlzY3Vzc2VkIGluIENoaWNhZ28sIHRo aXMgbWVzc2FnZSBiZWdpbnMgYSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRm LWlwcG0tYWx0LW1hcmssIHRvICB0byBydW4gdW50aWwgRU9CIENFU1QgKFVUQyArMikgVHVlc2Rh eSAyMCBKdW5lIDIwMTcuIFBsZWFzZSByZXBseSB0byBpcHBtQGlldGYub3JnPG1haWx0bzppcHBt QGlldGYub3JnPiBpbmRpY2F0aW5nIHdoZXRoZXIgeW91IGJlbGlldmUgdGhpcyBkb2N1bWVudCBp cyByZWFkeSBmb3IgcHVibGljYXRpb24sIGFuZCBpZiBub3QsIHdoeSBub3QuDQo+Pg0KPj4gTWFu eSB0aGFua3MsIGJlc3QgcmVnYXJkcywNCj4+DQo+PiBCcmlhbiAoYXMgSVBQTSBjby1jaGFpcikN Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBp cHBtIG1haWxpbmcgbGlzdA0KPj4gaXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4N Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBpcHBtIG1haWxp bmcgbGlzdA0KPiBpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCj4NCj4gUXVlc3RvIG1lc3NhZ2dp byBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUg cGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEg YXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkg c29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVz dG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFy bmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFs bGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQo+DQo+IFRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24s IGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2Vk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSBy ZXR1cm4gZS1tYWlsLCBUaGFua3MuDQo+DQo+IFJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFt cGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGluZyBsaXN0DQppcHBt QGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHBtDQoNCg0K --_000_8F0D52B3D9D840A4B51A474FF95EE38Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <85B355A2002E964CA991C527CBF0B0C6@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KR3JlZywNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rIHlvdSBmb3IgdGhlIGZv bGxvdy11cC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPldoYXQgeW91IHdyaXRlIGlzIHZlcnkgaW50ZXJlc3RpbmcgYnV0IGlycmVsZXZh bnQgYW5kIG9ydGhvZ29uYWwgdG8gbXkgY29tbWVudC4gSSBhbSBub3QgY29tbWVudGluZyBvbiBl cXVpdmFsZW5jeSBvZiByZXN1bHRzLiBJIGFtIGNvbW1lbnRpbmcgb24gbmFtaW5nIGFuZCBkZWZp bml0aW9uIG9mIHRlcm1zLiBJIHRoaW5rIEdpdXNlcHBl4oCZcyByZXNwb25zZSB3YXMgbW9yZSB1 c2VmdWw6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZndDsgW0dGXTogQWdyZWUsIHRoaXMgaXMgYW4g aW1wb3J0YW50IHBvaW50IHdlIHNob3VsZCBjbGFyaWZ5IHRvZ2V0aGVyIHdpdGggSVBQTS4mbmJz cDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoYW5rIHlvdSBmb3IgaW5pdGlhbGx5IHBvaW50aW5nIHRvIHRoZSBkZWZpbml0aW9ucyBp biBSRkMgNzc5OS4gSW5kZWVkLCB1bmRlciBzb21lIGNpcmN1bXN0YW5jZXMsIHBhc3NpdmUgYW5k IGh5YnJpZCBjYW4gcHJvZHVjZSBlcXVpdmFsZW50IHJlc3VsdHMuJm5ic3A7PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkhvd2V2ZXIsIHVuZGVyIGFsbCBjaXJjdW1zdGFuY2VzLCBoeWJyaWQgKmlzKiBo eWJyaWQsIGFuZCBwYXNzaXZlIGlzLCB3ZWxsLCBwYXNzaXZlLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlll cywgcmVzdWx0cyBjYW4gYmUgY29uc2lkZXJlZCBlcXVpdmFsZW50ICh1bmRlciBzb21lIGNpcmN1 bXN0YW5jZXMpLiBObywgd2UgY2Fubm90IHJlbmFtZSB0aGluZ3MuIE5vLCBlcXVpdmFsZW50IHJl c3VsdHMgZG9lcyBub3QgbWVhbiByZS1jYXRlZ29yaXphdGlvbi4mbmJzcDs8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+R2l2 ZW4gdGhlIGZhY3QgdGhhdCB0aGVyZSBhcmUgb3BlbiBxdWVzdGlvbnMgKHN1Y2ggYXMsIHdoYXQg aGFwcGVucyBmcm9tIGEgZGVmaW5pdGlvbiBwZXJzcGVjdGl2ZSBpZiB0aGVyZSBpcyBNYXJraW5n IGZvciBmaWVsZHMgdGhhdCBhcmUgYWN0dWFsbHkgcmVzZXJ2ZWQgZm9yIHRoaXMgZnVuY3Rpb25h bGl0eSBhcyBvcHBvc2VkIHRvIG92ZXJsb2FkaW5nIGZpZWxkcyksIEkgcmVjb21tZW5kIGEgc21h bGwgc3Vic2VjdGlvbg0KIG9mIHRoZSBJbnRybyBleHBsYWluaW5nIHRoZSBwcm9wZXIgY2F0ZWdv cml6YXRpb24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5BbmQgZ2l2ZW4gdGhlIGZhY3QgdGhhdCB0aGUgZmlyc3QgYnVsbGV0IGluIHRo ZSBkZWZpbml0aW9uIGF0Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc3OTkjc2VjdGlvbi0zLjYiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM3Nzk5I3NlY3Rpb24tMy42PC9hPiZuYnNwO2luY2x1ZGVzICZxdW90O3VuZGlzdHVyYmVk IGFuZCB1bm1vZGlmaWVk4oCdIGFuZCAmcXVvdDtNVVNUIE5PVCBb4oCmXSBjaGFuZ2UNCiBmaWVs ZCB2YWx1ZXPigJ0gd2hpY2ggaXMgcXVpdGUgdW5lcXVpdm9jYWwgb2YgYSBzdGF0ZW1lbnQuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5C ZXN0LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+4oCUIENhcmxvcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRp dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBK dW4gNywgMjAxNywgYXQgNDozNCBQTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpn cmVnaW1pcnNreUBnbWFpbC5jb20iIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5IaSBDYXJsb3MsDQo8ZGl2 IGNsYXNzPSIiPlJGQyA3Nzk5IGFja25vd2xlZGdlcyB0aGF0IHdpdGggcHJvcGVyIGluc3RydW1l bnRhdGlvbiBtZXRob2RzIHRoYXQgbW9kaWZ5IGRhdGEgcGFja2V0cyBtYXkgcHJvZHVjZSBtZWFz dXJlbWVudCByZXN1bHRzIGFzIHBhc3NpdmUgbWVhc3VyZW1lbnQgbWV0aG9kczo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXpl OiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+ICAgVGhl cmUgbWF5IGJlIGNpcmN1bXN0YW5jZXMgd2hlcmUgcmVzdWx0cyBtZWFzdXJlZCB3aXRoIEh5YnJp ZCBNZXRob2RzDQogICBjYW4gYmUgY29uc2lkZXJlZCBlcXVpdmFsZW50IHRvIHRob3NlIG1lYXN1 cmVkIHdpdGggUGFzc2l2ZSBNZXRob2RzLg0KPC9wcmU+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ SW4gdGhhdCBzZW5zZSB0aGUgQWx0ZXJuYXRlIE1hcmtpbmcgbWV0aG9kIG1heSBiZSBhcHBsaWVk IHNvIHRoYXQgaXMgYmVoYXZlcyBhbmQgcHJvZHVjZXMgcmVzdWx0cyBhcyBwYXNzaXZlIG1lYXN1 cmVtZW50IG1ldGhvZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdyZWc8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIEp1biA3LCAyMDE3IGF0IDk6NTIgQU0sIENhcmxvcyBQ aWduYXRhcm8gPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpj cGlnbmF0YUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5jcGlnbmF0YUBjaXNj by5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4 ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpDaWFvLCBHaXVzZXBwZSw8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpIYXBweSB0byBzdXBwb3J0IHRoaXMgZG9jdW1lbnQuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhZ3JlZSB3aXRoIGFsbCB5b3VyIHJlc3BvbnNlcy4g UGxlYXNlIGZpbmQgYSBjb3VwbGUgZm9sbG93dXBzIGlubGluZS48YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iaDUiPjxiciBjbGFzcz0iIj4NCiZndDsgT24gSnVuIDcs IDIwMTcsIGF0IDEyOjExIFBNLCBGaW9jY29sYSBHaXVzZXBwZSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmdpdXNlcHBlLmZpb2Njb2xhQHRlbGVjb21pdGFsaWEuaXQiIGNsYXNzPSIiPmdpdXNlcHBlLmZp b2Njb2xhQDx3YnIgY2xhc3M9IiI+dGVsZWNvbWl0YWxpYS5pdDwvYT4mZ3Q7IHdyb3RlOjxiciBj bGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFRoYW5rcyBmb3IgdGhlIHN1cHBvcnQs IENhcmxvcy48YnIgY2xhc3M9IiI+DQomZ3Q7IEFuc3dlcnMgdG8geW91ciBjb21tZW50cyBhcmUg aW5saW5lIHRhZ2dlZCBhcyBbR0ZdLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7IEdpdXNlcHBlPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgLS0tLS1N ZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS08YnIgY2xhc3M9IiI+DQomZ3Q7IERhOiBpcHBtIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZyIgY2xhc3M9IiI+aXBwbS1i b3VuY2VzQGlldGYub3JnPC9hPl0gUGVyIGNvbnRvIGRpIENhcmxvcyBQaWduYXRhcm8gKGNwaWdu YXRhKTxiciBjbGFzcz0iIj4NCiZndDsgSW52aWF0bzogbWFydGVkw6wgNiBnaXVnbm8gMjAxNyAx OTowMzxiciBjbGFzcz0iIj4NCiZndDsgQTogQnJpYW4gVHJhbW1lbGwgKElFVEYpPGJyIGNsYXNz PSIiPg0KJmd0OyBDYzogSUVURiBJUFBNIFdHPGJyIGNsYXNzPSIiPg0KJmd0OyBPZ2dldHRvOiBS ZTogW2lwcG1dIFdHTEMgb24gZHJhZnQtaWV0Zi1pcHBtLWFsdC1tYXJrPGJyIGNsYXNzPSIiPg0K Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgQnJpYW4sPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFz cz0iIj4NCiZndDsgSSBzdXBwb3J0IGFkdmFuY2luZyB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZl IGl04oCZcyByZWFkeSB0byBiZSBzZW50IHRvIHRoZSBJRVNHLjxiciBjbGFzcz0iIj4NCiZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7IFRoaXMgaXMgYW4gaW1wb3J0YW50IGRvY3VtZW50IGFuZCBmb3Vu ZGF0aW9uIHRvIHNwZWNpZmljIHByb3RvY29sIHJlYWxpemF0aW9ucywgYW5kIGl0cyBxdWFsaXR5 IGlzIHZlcnkgZ29vZC4gSSBhbHNvIGJlbGlldmUgdGhhdCBFeHBlcmltZW50YWwsIGFzIGN1cnJl bnRseSBpbnRlbmRlZCwgaXMgYXBwcm9wcmlhdGUuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFz cz0iIj4NCiZndDsgSSBkbyBoYXZlIGEgc2V0IG9mIGNvbW1lbnRzLCBmb3IgY29uc2lkZXJhdGlv biBhcyBwYXJ0IG9mIHRoaXMgV0dMQy48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyBXaGlsZSB0aGUgbWV0aG9kIGl0c2VsZiBpcyBkZXNjcmliZWQgaW4gZ3JlYXQgZGV0YWls IGFuZCB3aXRoIGNhcmUsIHNvbWUgY29udGV4dHVhbCBpbmZvcm1hdGlvbiBhbmQgdGV4dCBhcm91 bmQganVzdGlmaWNhdGlvbnMgb3IgcG90ZW50aWFsIGZ1dHVyZSBpbXBsZW1lbnRhdGlvbiBpcyBh IGJpdCBtb3JlIGxvb3NlLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IENv bW1lbnRzOjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEEuIFRpdGxlIGFu ZCBtZXRob2Q8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBUaGUgdGl0bGUg b2YgdGhpcyBkb2N1bWVudCBpcyDigJxBbHRlcm5hdGUgTWFya2luZyBtZXRob2QgZm9yIHBhc3Np dmUgcGVyZm9ybWFuY2UgbW9uaXRvcmluZ+KAnS48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyBIb3dldmVyLCBhcyBHcmVnIE1pcnNreSByZXBlYXRlZGx5IG1lbnRpb25lZCBp biBkaWZmZXJlbnQgY29udGV4dHMsIGxldOKAmXMgdXNlIElFVEYgZGVmaW5pdGlvbnMgb3IgYWN0 aXZlL3Bhc3NpdmUvaW5iYW5kL2V0Yy4gQXMgc3VjaCwgUGFzc2l2ZSBtb25pdG9yaW5nIGRvZXMg bm90IG1vZGlmeSBwYWNrZXRzLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 IEJhc2VkIG9uIHRoZSBkZWZpbml0aW9uIGF0IFJGQyA3Nzk5ICh3aGljaCBpcyBub3QgcmVmZXJl bmNlZCk6PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc3OTkjc2VjdGlvbi0zLjYiIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sLzx3YnIgY2xhc3M9IiI+cmZjNzc5OSNzZWN0aW9uLTMuNjwvYT48YnIgY2xhc3M9IiI+DQom Z3Q7IDMuNi4mbmJzcDsgUGFzc2l2ZSBNZXRob2RzPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFz cz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7UGFzc2l2ZSBNZXRob2RzIG9mIE1lYXN1cmVtZW50IGFy ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDtvJm5i c3A7IGJhc2VkIHNvbGVseSBvbiBvYnNlcnZhdGlvbnMgb2YgYW4gdW5kaXN0dXJiZWQgYW5kIHVu bW9kaWZpZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcGFja2V0IHN0 cmVhbSBvZiBpbnRlcmVzdCAoaW4gb3RoZXIgd29yZHMsIHRoZSBtZXRob2Qgb2Y8YnIgY2xhc3M9 IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbWVhc3VyZW1lbnQgTVVTVCBOT1QgYWRkLCBj aGFuZ2UsIG9yIHJlbW92ZSBwYWNrZXRzIG9yIGZpZWxkcyBvcjxiciBjbGFzcz0iIj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyBjaGFuZ2UgZmllbGQgdmFsdWVzIGFueXdoZXJlIGFsb25nIHRo ZSBwYXRoKS48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBTYXlpbmcg4oCc bWFya2luZyBmb3IgcGFzc2l2ZeKAnSBpcywgYmFzZWQgb24gdGhpcyBkZWZpbml0aW9uLCBhbiBv eHltb3Jvbi4gTWFya2luZyAvIGNvbG9yaW5nIHdvdWxkIGdvIGFnYWluc3QgdGhlIGRlZmluaXRp b24gb2YgcGFzc2l2ZS48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBbR0Zd OiBBZ3JlZSwgdGhpcyBpcyBhbiBpbXBvcnRhbnQgcG9pbnQgd2Ugc2hvdWxkIGNsYXJpZnkgdG9n ZXRoZXIgd2l0aCBJUFBNLiBBIHJlZmVyZW5jZSB0byBSRkM3Nzk5IGNhbiBiZSBhZGRlZC4gSW4g bXkgb3BpbmlvbiwgbWFya2luZyBtZXRob2QgY291bGQgYmUgY29uc2lkZXJlZCBoeWJyaWQgb3Ig cGFzc2l2ZSBkZXBlbmRpbmcgb24gdGhlIGNhc2UuIEluIGNhc2UgdGhlIG1hcmtpbmcgYml0cyBh cmUgcGFydCBvZiB0aGUgRFNDUCBmaWVsZA0KIChhcyBhbiBleGFtcGxlKSB0aGUgdGVjaG5pcXVl IGlzIGh5YnJpZC4gSW4gY2FzZSB0aGUgbWFya2luZyBiaXRzIGFyZSBkZWRpY2F0ZWQgYW5kIHJl c2VydmVkIGFuZCBhcmUgaW5jbHVkZWQgaW4gdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24gKGUu Zy4gQklFUikgbWFya2luZyB0ZWNobmlxdWUgY2FuIGJlIGNvbnNpZGVyZWQgYXMgcGFzc2l2ZS4g SSBzdWdnZXN0IHRvIGFkZCBhbHNvIGh5YnJpZCBpbiB0aGUgdGl0bGUuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCkNNUDogSSBhZ3JlZSB3aXRoIHlvdSBvdmVy YWxsLiBJIGJlbGlldmUgYSB2ZXJ5IHNtYWxsIG5ldyBzdWJzZWN0aW9uIHdpdGhpbiB0aGUgSW50 cm9kdWN0aW9uLCBzcGVha2luZyB0byB0aGUgY2F0ZWdvcml6YXRpb24sIGFzIHdlbGwgYXMgYSBw b3RlbnRpYWwgdGl0bGUgdXBkYXRlIHdpbGwgYWRkcmVzcyB0aGlzIGNvbW1lbnQuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KQ01QOiBBbmQgSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQg ZnJvbSBJUFBNIHdoZXRoZXIgc2V0dGluZyBvciBjbGVhcmluZyBwcmUtYWxsb2NhdGVkIGJpdHMg aXMgcmVhbGx5IHBhc3NpdmUgKHNpbmNlIFJGQyA3Nzk5IHNheXMg4oCcIE1VU1QgTk9UIGNoYW5n ZSBmaWVsZCB2YWx1ZXPigJ0gZm9yIFBhc3NpdmUuKTxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEIuIFNwZWNpZmljIGNv bW1lbnRzOjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IDEuJm5ic3A7IElu dHJvZHVjdGlvbjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZu YnNwO05vd2FkYXlzLCBtb3N0IG9mIHRoZSB0cmFmZmljIGluIFNlcnZpY2UgUHJvdmlkZXJzJyBu ZXR3b3JrcyBjYXJyaWVzPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDtyZWFsIHRpbWUg Y29udGVudC48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBDTVA6IFdoaWxl IEkgZG8gbm90IGRpc3B1dGUgdGhhdCBzdGF0ZW1lbnQsIGEgY2l0YXRpb24gd291bGQgbm90IGh1 cnQgdG8gc3VwcG9ydCB0aGUgZGVmaW5pdGl2ZW5lc3Mgb2YgdGhlIHZlcnkgZmlyc3Qgc2VudGVu Y2Ugc2V0dGluZyB0aGUgdG9uZSBmb3IgdGhlIHdob2xlIGRvY3VtZW50LjxiciBjbGFzcz0iIj4N CiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFtHRl06IEFncmVlLCB3ZSBjYW4gZXh0ZW5kIHRoaXMg c3RhdGVtZW50LjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IENNUDogU2Vj dGlvbnMgMi00IGxvb2sgZ3JlYXQuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZn dDsgQ01QOiBJIHRoaW5rIHRoZXJlIGFyZSBpc3N1ZXMgaW4gU2VjdGlvbiA1LiBTZWN0aW9uIDUg c2hvdWxkIGNvdmVyIHRoZSBmb2xsb3dpbmc6PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmbmJzcDsgJm5ic3A7byZuYnNwOyBTZWN0aW9uIDUgcmVwb3J0cyBleGFtcGxlcyBv ZiBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudCBvZiB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbWV0aG9kLiZuYnNwOyBGdXJ0aGVybW9yZSB0aGUgb3BlcmF0 aW9uYWwgZXhwZXJpbWVudCBkb25lIGF0IFRlbGVjb208YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgSXRhbGlhIGlzIGRlc2NyaWJlZDs8YnIgY2xhc3M9IiI+DQomZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyBDTVA6IEFuZCBTZWN0aW9uIDUuMSBpcyBwZXJmZWN0IGFuZCBkZXNj cmliZXMgZXhhY3RseSB0aGUgZXhhbXBsZSBvZiBpbXBsZW1lbnRhdGlvbi4gSG93ZXZlcjo8YnIg Y2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyA1LjMuJm5ic3A7IFBlcmZvcm1hbmNl IE1lYXN1cmVtZW50IE1hcmtpbmcgTWV0aG9kIGluIEJJRVIgRG9tYWluPGJyIGNsYXNzPSIiPg0K Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgQ01QOiBUaGUgZHJhZnQgaW5oZXJlbnRseSBkZXNjcmli ZXMgYSB1bmljYXN0IHNlcnZpY2UsIG5vdCBzdXJlIGlmIHRoaXMgZG9jdW1lbnQgaXMgbm90IHNj b3BlZCB0byBjbGFpbSB0aGlzIHN1Yi1zZWN0aW9uLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7IFtHRl06IEhlcmUgaXMgYW4gZXhhbXBsZSBvbiBob3cgdG8gdXNlIHRoaXMg bWV0aG9kIGFzIHBhc3NpdmUuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsg NS40LiZuYnNwOyBPdmVybGF5IE9BTSBQYXNzaXZlIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50PGJy IGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7VGhlIE92ZXJs YXkgT0FNIERlc2lnbiBUZWFtIGlzIGNvbnNpZGVyaW5nIHRoZSBwcmVsaW1pbmFyeSBPQU08YnIg Y2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3JlcXVpcmVtZW50cyBmcm9tIE5WTzMsIEJJRVIs IGFuZCBTRkMuJm5ic3A7IE1hcmtpbmcgTWV0aG9kIGlzIHRoZTxiciBjbGFzcz0iIj4NCiZndDsm bmJzcDsgJm5ic3A7cHJlZmVycmVkIHBhc3NpdmUgbWV0aG9kIHRvIG1lYXN1cmUgcGVyZm9ybWFu Y2UuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7W0kt RC5vb2FtZHQtcnRnd2ctb29hbS08d2JyIGNsYXNzPSIiPnJlcXVpcmVtZW50XSBhbmQ8YnIgY2xh c3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1tJLUQub29hbWR0LXJ0Z3dnLW9hbS1nYXAtPHdiciBj bGFzcz0iIj5hbmFseXNpc10gZXhwbGFpbiBpbiBkZWVwIHRoaXMgaXRlbS48YnIgY2xhc3M9IiI+ DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBDTVA6IFRoaXMgdG8gbWUgaXMgYSBncm9zcyBleHRy YXBvbGF0aW9uLiBUaGUgdGV4dCBhcyB3cml0dGVuIGlzIHNpbXBseSBpbmNvcnJlY3QsIGFuZCB0 aGVyZeKAmXMgbm8gbWF0dXJpdHkgb3IgYnJvYWQgYWxpZ25tZW50IHRvIGluY2x1ZGUgdGhpcyBJ IHJlY29tbWVuZCByZW1vdmluZyB0aGlzIHdob2xlIFNlY3Rpb24gNS40LjxiciBjbGFzcz0iIj4N CiZndDsgQ01QOiBUaGlzIGlzIG5laXRoZXIg4oCcZXhhbXBsZXMgb2YgaW1wbGVtZW50YXRpb24g b3IgZGVwbG95bWVudOKAnS48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBb R0ZdOiBZZXMsIHRoaXMgaXMgaW5oZXJpdGVkIGJ5IG9sZCB2ZXJzaW9ucyBvZiB0aGUgZG9jdW1l bnQuIEl0IHdpbGwgYmUgZGVsZXRlZCBvciByZXBocmFzZWQuPGJyIGNsYXNzPSIiPg0KJmd0Ozxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvc3Bhbj5DTVA6IEkgd291bGQgcmVjb21tZW5k IGRlbGV0aW5nIGl0IGFzIGl0IGFwcGVhcnMgb2xkIG5vaXNlLjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NClRoYW5rcyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpDYXJsb3MuPGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iSE9FblpiIj4NCjxkaXYgY2xhc3M9Img1Ij48YnIgY2xh c3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBOZXQtbmV0LCBJIHN1cHBvcnQgdGhpcyBk b2N1bWVudCBidXQgcmVjb21tZW5kIHRoZXNlIGNvbW1lbnRzIGFyZSBhZGRyZXNzZWQuPGJyIGNs YXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgVGhhbmtzLDxiciBjbGFzcz0iIj4NCiZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7IOKAlCBDYXJsb3MuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBj bGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg T24gTWF5IDMwLCAyMDE3LCBhdCAxMTo1MyBBTSwgQnJpYW4gVHJhbW1lbGwgKElFVEYpICZsdDs8 YSBocmVmPSJtYWlsdG86aWV0ZkB0cmFtbWVsbC5jaCIgY2xhc3M9IiI+aWV0ZkB0cmFtbWVsbC5j aDwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgR3JlZXRpbmdzLCBJUFBNLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgQXMgZGlzY3Vzc2VkIGluIENoaWNhZ28sIHRoaXMgbWVzc2FnZSBiZWdpbnMg YSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWlwcG0tYWx0LW1hcmssIHRv Jm5ic3A7IHRvIHJ1biB1bnRpbCBFT0IgQ0VTVCAoVVRDICYjNDM7MikgVHVlc2RheSAyMCBKdW5l IDIwMTcuIFBsZWFzZSByZXBseSB0bw0KPGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIGNs YXNzPSIiPmlwcG1AaWV0Zi5vcmc8L2E+IGluZGljYXRpbmcgd2hldGhlciB5b3UgYmVsaWV2ZSB0 aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYW5kIGlmIG5vdCwgd2h5IG5v dC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IE1hbnkgdGhh bmtzLCBiZXN0IHJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyBCcmlhbiAoYXMgSVBQTSBjby1jaGFpcik8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2JyIGNsYXNzPSIiPl9fX19fX19fX19fX19f X19fPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgaXBwbSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgY2xhc3M9IiI+aXBwbUBp ZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyIGNsYXNz PSIiPmxpc3RpbmZvL2lwcG08L2E+PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdiciBjbGFzcz0iIj5fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NCiZndDsgaXBwbSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+ DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIiBjbGFzcz0iIj5pcHBtQGlldGYu b3JnPC9hPjxiciBjbGFzcz0iIj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcHBtIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBj bGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdiciBjbGFzcz0iIj5saXN0 aW5mby9pcHBtPC9hPjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFF1ZXN0 byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFt ZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNp YXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5m b3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmlj ZXZ1dG8gcXVlc3RvIGRvY3VtZW50bw0KIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHBy ZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBw cm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuPGJyIGNsYXNzPSIiPg0KJmd0 OzxiciBjbGFzcz0iIj4NCiZndDsgVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBj b25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5k ZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJp bnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlDQog YW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFp bCwgVGhhbmtzLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFJpc3BldHRh IGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJp by48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX188d2JyIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KaXBwbSBt YWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIg Y2xhc3M9IiI+aXBwbUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0iIHJlbD0ibm9yZWZlcnJlciIgdGFy Z2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdiciBj bGFzcz0iIj5saXN0aW5mby9pcHBtPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_8F0D52B3D9D840A4B51A474FF95EE38Aciscocom_-- From nobody Wed Jun 7 14:16:59 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE2F12947A for ; Wed, 7 Jun 2017 14:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 l3672qgCbABM for ; Wed, 7 Jun 2017 14:16:54 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2FF126C22 for ; Wed, 7 Jun 2017 14:16:54 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id o65so11026318oif.1 for ; Wed, 07 Jun 2017 14:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S7lmKcPGNOFajzmkkbB0R/wVBLu0uKAfyKxBYNOjNPc=; b=QvJF+BO5MMfQw8n0JXGx0fjo3P2FgpD1WxfX3Gyo+kZgRzA1Qh6wM5uWYB8/J46iU9 Dq5tNlmZYGVqWXKRfMsQGU6HYttUbdpfqt+eGP8z0Wfw8NnOqswtS0AkmdDe4IlsUP6G Zibd/A2aJnb+GFlqJ7Oz9M6b+L8JKQb6JmFJVxN0VAA+QKu99N1eRKrj1mJETVQAxIA3 S/2RnbLugOvGN6N7xNCR+BYNJc29lnWcT/awkkGR2ZAJzPWZ3eECypk1roxIawZyOFpJ 8R9lXZSKKMxrKYNKrgtXQMtFPUa+vhojzFq+UBeTfibi8IkNCIKYfuf5noEXWCvhi28u cCKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S7lmKcPGNOFajzmkkbB0R/wVBLu0uKAfyKxBYNOjNPc=; b=c47a8r2BcooMRTlD+ntZh4iZGI4zHCynNEMMo24s1o2l5Te+S9299V04wbMLVh3X2q yPtoizKKrEcgux4ynOHX1W8SviXEwFKF+m/xIVCJrM7oiipO+iPo3nXV+CKj5B0RAMxQ r0iFxReYkft/vCNnRpOQg7DxetiJMXbbNB1r8OfkO/CE8I1t+piDPiTUT20dkCK9Cd1p /2befe/gXYy/BsYfnS24G+uXGawXW9UB1+bf/EKG5n19//Qd2v3kP8zxu64SyiGNUMSs Rm5NuKMpQCtVnvauEhBUHSyQeYXEsa9yhBKFffn7TSRt+Zzc/2Lob14YQNqglxlLkMs5 QXqg== X-Gm-Message-State: AODbwcDta5BtCv0AF/az9JSwr1+mXIcL4AXxNPaTnun9qR15pGF/2W6C xAfuP2b0SryOqJJhGH0TaFP67l8Q6g== X-Received: by 10.202.108.17 with SMTP id h17mr18678715oic.161.1496870213502; Wed, 07 Jun 2017 14:16:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.225 with HTTP; Wed, 7 Jun 2017 14:16:53 -0700 (PDT) In-Reply-To: <8F0D52B3-D9D8-40A4-B51A-474FF95EE38A@cisco.com> References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> <8eae12d5997b4b50b774299b06f0c7c7@TELMBXB02RM001.telecomitalia.local> <8F0D52B3-D9D8-40A4-B51A-474FF95EE38A@cisco.com> From: Greg Mirsky Date: Wed, 7 Jun 2017 14:16:53 -0700 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: Fioccola Giuseppe , IETF IPPM WG Content-Type: multipart/alternative; boundary="001a1142e7ee59cd050551654127" Archived-At: Subject: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 21:16:57 -0000 --001a1142e7ee59cd050551654127 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, I'm not against clarification that would refer to the Alternate Marking method as Hybrid per RFC 7799 that can be applied to a network in the manner so it behaves and produces results as Passive method. Hope such clarification would address your concern. Regards, Greg On Wed, Jun 7, 2017 at 2:02 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Greg, > > Thank you for the follow-up. > > What you write is very interesting but irrelevant and orthogonal to my > comment. I am not commenting on equivalency of results. I am commenting o= n > naming and definition of terms. I think Giuseppe=E2=80=99s response was m= ore useful: > > [GF]: Agree, this is an important point we should clarify together with > IPPM. > > Thank you for initially pointing to the definitions in RFC 7799. Indeed, > under some circumstances, passive and hybrid can produce equivalent > results. > However, under all circumstances, hybrid *is* hybrid, and passive is, > well, passive. > > Yes, results can be considered equivalent (under some circumstances). No, > we cannot rename things. No, equivalent results does not mean > re-categorization. > > Given the fact that there are open questions (such as, what happens from = a > definition perspective if there is Marking for fields that are actually > reserved for this functionality as opposed to overloading fields), I > recommend a small subsection of the Intro explaining the proper > categorization. > > And given the fact that the first bullet in the definition at > https://tools.ietf.org/html/rfc7799#section-3.6 includes "undisturbed and > unmodified=E2=80=9D and "MUST NOT [=E2=80=A6] change field values=E2=80= =9D which is quite > unequivocal of a statement. > > Best, > > =E2=80=94 Carlos. > > On Jun 7, 2017, at 4:34 PM, Greg Mirsky wrote: > > Hi Carlos, > RFC 7799 acknowledges that with proper instrumentation methods that modif= y > data packets may produce measurement results as passive measurement metho= ds: > > There may be circumstances where results measured with Hybrid Methods > can be considered equivalent to those measured with Passive Methods. > > In that sense the Alternate Marking method may be applied so that is > behaves and produces results as passive measurement method. > > Regards, > Greg > > On Wed, Jun 7, 2017 at 9:52 AM, Carlos Pignataro > wrote: > >> Ciao, Giuseppe, >> >> Happy to support this document. >> >> I agree with all your responses. Please find a couple followups inline. >> >> > On Jun 7, 2017, at 12:11 PM, Fioccola Giuseppe < >> giuseppe.fioccola@telecomitalia.it> wrote: >> > >> > Thanks for the support, Carlos. >> > Answers to your comments are inline tagged as [GF]. >> > >> > Giuseppe >> > >> > -----Messaggio originale----- >> > Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Carlos Pignataro >> (cpignata) >> > Inviato: marted=C3=AC 6 giugno 2017 19:03 >> > A: Brian Trammell (IETF) >> > Cc: IETF IPPM WG >> > Oggetto: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark >> > >> > Brian, >> > >> > I support advancing this document and believe it=E2=80=99s ready to be= sent to >> the IESG. >> > >> > This is an important document and foundation to specific protocol >> realizations, and its quality is very good. I also believe that >> Experimental, as currently intended, is appropriate. >> > >> > I do have a set of comments, for consideration as part of this WGLC. >> > >> > While the method itself is described in great detail and with care, >> some contextual information and text around justifications or potential >> future implementation is a bit more loose. >> > >> > Comments: >> > >> > A. Title and method >> > >> > The title of this document is =E2=80=9CAlternate Marking method for pa= ssive >> performance monitoring=E2=80=9D. >> > >> > However, as Greg Mirsky repeatedly mentioned in different contexts, >> let=E2=80=99s use IETF definitions or active/passive/inband/etc. As such= , Passive >> monitoring does not modify packets. >> > >> > Based on the definition at RFC 7799 (which is not referenced): >> > >> > https://tools.ietf.org/html/rfc7799#section-3.6 >> > 3.6. Passive Methods >> > >> > Passive Methods of Measurement are: >> > >> > o based solely on observations of an undisturbed and unmodified >> > packet stream of interest (in other words, the method of >> > measurement MUST NOT add, change, or remove packets or fields or >> > change field values anywhere along the path). >> > >> > Saying =E2=80=9Cmarking for passive=E2=80=9D is, based on this definit= ion, an oxymoron. >> Marking / coloring would go against the definition of passive. >> > >> > [GF]: Agree, this is an important point we should clarify together wit= h >> IPPM. A reference to RFC7799 can be added. In my opinion, marking method >> could be considered hybrid or passive depending on the case. In case the >> marking bits are part of the DSCP field (as an example) the technique is >> hybrid. In case the marking bits are dedicated and reserved and are >> included in the protocol specification (e.g. BIER) marking technique can= be >> considered as passive. I suggest to add also hybrid in the title. >> >> CMP: I agree with you overall. I believe a very small new subsection >> within the Introduction, speaking to the categorization, as well as a >> potential title update will address this comment. >> >> CMP: And I would like to understand from IPPM whether setting or clearin= g >> pre-allocated bits is really passive (since RFC 7799 says =E2=80=9C MUST= NOT change >> field values=E2=80=9D for Passive.) >> >> > >> > B. Specific comments: >> > >> > 1. Introduction >> > >> > Nowadays, most of the traffic in Service Providers' networks carries >> > real time content. >> > >> > CMP: While I do not dispute that statement, a citation would not hurt >> to support the definitiveness of the very first sentence setting the ton= e >> for the whole document. >> > >> > [GF]: Agree, we can extend this statement. >> > >> > CMP: Sections 2-4 look great. >> > >> > CMP: I think there are issues in Section 5. Section 5 should cover the >> following: >> > >> > o Section 5 reports examples of implementation and deployment of th= e >> > method. Furthermore the operational experiment done at Telecom >> > Italia is described; >> > >> > CMP: And Section 5.1 is perfect and describes exactly the example of >> implementation. However: >> > >> > 5.3. Performance Measurement Marking Method in BIER Domain >> > >> > CMP: The draft inherently describes a unicast service, not sure if thi= s >> document is not scoped to claim this sub-section. >> > >> > [GF]: Here is an example on how to use this method as passive. >> > >> > 5.4. Overlay OAM Passive Performance Measurement >> > >> > The Overlay OAM Design Team is considering the preliminary OAM >> > requirements from NVO3, BIER, and SFC. Marking Method is the >> > preferred passive method to measure performance. >> > >> > [I-D.ooamdt-rtgwg-ooam-requirement] and >> > [I-D.ooamdt-rtgwg-oam-gap-analysis] explain in deep this item. >> > >> > CMP: This to me is a gross extrapolation. The text as written is simpl= y >> incorrect, and there=E2=80=99s no maturity or broad alignment to include= this I >> recommend removing this whole Section 5.4. >> > CMP: This is neither =E2=80=9Cexamples of implementation or deployment= =E2=80=9D. >> > >> > [GF]: Yes, this is inherited by old versions of the document. It will >> be deleted or rephrased. >> > >> >> CMP: I would recommend deleting it as it appears old noise. >> >> Thanks, >> >> Carlos. >> >> > >> > Net-net, I support this document but recommend these comments are >> addressed. >> > >> > Thanks, >> > >> > =E2=80=94 Carlos. >> > >> > >> > >> >> On May 30, 2017, at 11:53 AM, Brian Trammell (IETF) >> wrote: >> >> >> >> Greetings, IPPM, >> >> >> >> As discussed in Chicago, this message begins a Working Group Last Cal= l >> on draft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday = 20 >> June 2017. Please reply to ippm@ietf.org indicating whether you believe >> this document is ready for publication, and if not, why not. >> >> >> >> Many thanks, best regards, >> >> >> >> Brian (as IPPM co-chair) >> >> _______________________________________________ >> >> 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 >> > >> > Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e >> persone indicate. La diffusione, copia o qualsiasi altra azione derivant= e >> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qual= ora >> abbiate ricevuto questo documento per errore siete cortesemente pregati = di >> darne immediata comunicazione al mittente e di provvedere alla sua >> distruzione, Grazie. >> > >> > This e-mail and any attachments is confidential and may contain >> privileged information intended for the addressee(s) only. Dissemination= , >> copying, printing or use by anybody else is unauthorised. If you are not >> the intended recipient, please delete this message and any attachments a= nd >> advise the sender by return e-mail, Thanks. >> > >> > Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 necessario= . >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > > > --001a1142e7ee59cd050551654127 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,
I'm not against clarification that woul= d refer to the Alternate Marking method as Hybrid per RFC 7799 that can be = applied to a network in the manner so it behaves and produces results as Pa= ssive method. Hope such clarification would address your concern.

Regards,
Greg

On Wed, Jun 7, 2017 at 2:02 PM, Carlos Pi= gnataro (cpignata) <cpignata@cisco.com> wrote:
Greg,

Thank you for the follow-up.

What you write is very interesting but irrelevant and orthogonal to my= comment. I am not commenting on equivalency of results. I am commenting on= naming and definition of terms. I think Giuseppe=E2=80=99s response was mo= re useful:
> [GF]: Agree, this is an important point we should clarify togethe= r with IPPM.=C2=A0

Thank you for initially pointing to the definitions in RFC 7799= . Indeed, under some circumstances, passive and hybrid can produce equivale= nt results.=C2=A0
However, under all circumstances, hybrid *is* hybrid, and passive is, = well, passive.

Yes, results can be considered equivalent (under some circumstances). = No, we cannot rename things. No, equivalent results does not mean re-catego= rization.=C2=A0

Given the fact that there are open questions (such as, what happens fr= om a definition perspective if there is Marking for fields that are actuall= y reserved for this functionality as opposed to overloading fields), I reco= mmend a small subsection of the Intro explaining the proper categorization.

And given the fact that the first bullet in the definition at=C2=A0= https://tools.ietf.org/html/rfc7799#section-3.6=C2=A0includes= "undisturbed and unmodified=E2=80=9D and "MUST NOT [=E2=80=A6] c= hange field values=E2=80=9D which is quite unequivocal of a statement.

Best,

=E2=80=94 Carlos.

On Jun 7, 2017, at 4:34 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
RFC 7799 acknowledges that with proper instrumentation methods that mo= dify data packets may produce measurement results as passive measurement me= thods:
   There may be circumstances where =
results measured with Hybrid Methods
   can be considered equivalent to those measured with Passive Methods.
In that sense the Alternate Marking method may be applied so that is b= ehaves and produces results as passive measurement method.

Regards,
Greg

On Wed, Jun 7, 2017 at 9:52 AM, Carlos Pignataro= <cpignata@cisco.= com> wrote:
Ciao, Giuseppe,

Happy to support this document.

I agree with all your responses. Please find a couple followups inline.

> On Jun 7, 2017, at 12:11 PM, Fioccola Giuseppe <giuseppe.fioccola@tele= comitalia.it> wrote:
>
> Thanks for the support, Carlos.
> Answers to your comments are inline tagged as [GF].
>
> Giuseppe
>
> -----Messaggio originale-----
> Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Carlos Pignataro (cpignata) > Inviato: marted=C3=AC 6 giugno 2017 19:03
> A: Brian Trammell (IETF)
> Cc: IETF IPPM WG
> Oggetto: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark
>
> Brian,
>
> I support advancing this document and believe it=E2=80=99s ready to be= sent to the IESG.
>
> This is an important document and foundation to specific protocol real= izations, and its quality is very good. I also believe that Experimental, a= s currently intended, is appropriate.
>
> I do have a set of comments, for consideration as part of this WGLC. >
> While the method itself is described in great detail and with care, so= me contextual information and text around justifications or potential futur= e implementation is a bit more loose.
>
> Comments:
>
> A. Title and method
>
> The title of this document is =E2=80=9CAlternate Marking method for pa= ssive performance monitoring=E2=80=9D.
>
> However, as Greg Mirsky repeatedly mentioned in different contexts, le= t=E2=80=99s use IETF definitions or active/passive/inband/etc. As such, Pas= sive monitoring does not modify packets.
>
> Based on the definition at RFC 7799 (which is not referenced):
>
> https://tools.ietf.org/html/rfc7799#section-3.6
> 3.6.=C2=A0 Passive Methods
>
>=C2=A0 =C2=A0Passive Methods of Measurement are:
>
>=C2=A0 =C2=A0o=C2=A0 based solely on observations of an undisturbed and= unmodified
>=C2=A0 =C2=A0 =C2=A0 packet stream of interest (in other words, the met= hod of
>=C2=A0 =C2=A0 =C2=A0 measurement MUST NOT add, change, or remove packet= s or fields or
>=C2=A0 =C2=A0 =C2=A0 change field values anywhere along the path).
>
> Saying =E2=80=9Cmarking for passive=E2=80=9D is, based on this definit= ion, an oxymoron. Marking / coloring would go against the definition of pas= sive.
>
> [GF]: Agree, this is an important point we should clarify together wit= h IPPM. A reference to RFC7799 can be added. In my opinion, marking method = could be considered hybrid or passive depending on the case. In case the ma= rking bits are part of the DSCP field (as an example) the technique is hybrid. In case the marking bits are dedi= cated and reserved and are included in the protocol specification (e.g. BIE= R) marking technique can be considered as passive. I suggest to add also hy= brid in the title.

CMP: I agree with you overall. I believe a very small new subsection within= the Introduction, speaking to the categorization, as well as a potential t= itle update will address this comment.

CMP: And I would like to understand from IPPM whether setting or clearing p= re-allocated bits is really passive (since RFC 7799 says =E2=80=9C MUST NOT= change field values=E2=80=9D for Passive.)

>
> B. Specific comments:
>
> 1.=C2=A0 Introduction
>
>=C2=A0 =C2=A0Nowadays, most of the traffic in Service Providers' ne= tworks carries
>=C2=A0 =C2=A0real time content.
>
> CMP: While I do not dispute that statement, a citation would not hurt = to support the definitiveness of the very first sentence setting the tone f= or the whole document.
>
> [GF]: Agree, we can extend this statement.
>
> CMP: Sections 2-4 look great.
>
> CMP: I think there are issues in Section 5. Section 5 should cover the= following:
>
>=C2=A0 =C2=A0o=C2=A0 Section 5 reports examples of implementation and d= eployment of the
>=C2=A0 =C2=A0 =C2=A0 method.=C2=A0 Furthermore the operational experime= nt done at Telecom
>=C2=A0 =C2=A0 =C2=A0 Italia is described;
>
> CMP: And Section 5.1 is perfect and describes exactly the example of i= mplementation. However:
>
> 5.3.=C2=A0 Performance Measurement Marking Method in BIER Domain
>
> CMP: The draft inherently describes a unicast service, not sure if thi= s document is not scoped to claim this sub-section.
>
> [GF]: Here is an example on how to use this method as passive.
>
> 5.4.=C2=A0 Overlay OAM Passive Performance Measurement
>
>=C2=A0 =C2=A0The Overlay OAM Design Team is considering the preliminary= OAM
>=C2=A0 =C2=A0requirements from NVO3, BIER, and SFC.=C2=A0 Marking Metho= d is the
>=C2=A0 =C2=A0preferred passive method to measure performance.
>
>=C2=A0 =C2=A0[I-D.ooamdt-rtgwg-ooam-requirement] and
>=C2=A0 =C2=A0[I-D.ooamdt-rtgwg-oam-gap-analysis] explain in deep t= his item.
>
> CMP: This to me is a gross extrapolation. The text as written is simpl= y incorrect, and there=E2=80=99s no maturity or broad alignment to include = this I recommend removing this whole Section 5.4.
> CMP: This is neither =E2=80=9Cexamples of implementation or deployment= =E2=80=9D.
>
> [GF]: Yes, this is inherited by old versions of the document. It will = be deleted or rephrased.
>

CMP: I would recommend deleting it as it appears old noise.

Thanks,

Carlos.

>
> Net-net, I support this document but recommend these comments are addr= essed.
>
> Thanks,
>
> =E2=80=94 Carlos.
>
>
>
>> On May 30, 2017, at 11:53 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:=
>>
>> Greetings, IPPM,
>>
>> As discussed in Chicago, this message begins a Working Group Last = Call on draft-ietf-ippm-alt-mark, to=C2=A0 to run until EOB CEST (UTC +2) T= uesday 20 June 2017. Please reply to ippm@ietf.org indica= ting whether you believe this document is ready for publication, and if not= , why not.
>>
>> Many thanks, best regards,
>>
>> Brian (as IPPM co-chair)
>> _______________________________________________
>> 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
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e persone indicate. La diffusione, copia o qualsiasi altra azione derivante= dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualor= a abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al = mittente e di provvedere alla sua distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privil= eged information intended for the addressee(s) only. Dissemination, copying= , printing or use by anybody else is unauthorised. If you are not the inten= ded recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
>
> Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 necess= ario.

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



--001a1142e7ee59cd050551654127-- From nobody Wed Jun 7 22:32:24 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BE4129B83 for ; Wed, 7 Jun 2017 22:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 71YwrsPeUFI5 for ; Wed, 7 Jun 2017 22:32:20 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDEF81274D2 for ; Wed, 7 Jun 2017 22:32:19 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id d73so23406624wma.0 for ; Wed, 07 Jun 2017 22:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vJ57AIq9fCWERI3JRMK/2aiWJdFrnQPCXQe6lp3g+yU=; b=lPtwqTncRcZfErJJkMStex3Oq+WESemDxnG4hk4DY7hlkQ2mph31M3BEi4+JjSAoFy GSqf1C56li5psdT+Zqx8+75YkNcr5xb5rHOtg7j9PIyDjq4NVHUVvXo1UgIa2uAm+bIs Yir0bnruV3/05O6EEaJ3bv1UnxxI/wf5ONSdWKjTqg4lqRDBlZpvDLBASyLvpCe+F+E9 bLz+3ud/LwEyGWWEcb8kiAatSeWqVLmc6yx9myTALRe/wofO4kt2eAFsSLSx/5R/deEc SImRbbDHNL8gfrPd3yimjrRs0jk7xJVtq5+qELuoaXxZS5SEJBFbazEgE5Ll1ghDdPil Ln2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vJ57AIq9fCWERI3JRMK/2aiWJdFrnQPCXQe6lp3g+yU=; b=LdTED9mYzDUP7LmkieLB98otaB+YA6j/OGf2jPaa5vaE47wGxQ7UxmxSeYxK3Wcrd4 7LOP1yaxUwVE41oSb66746+opkM8Arh52RrcEyPyA5IvlY8+VUW/8csQD5DGvCILsX76 d+M5ooIil91i65vCs/OV7vvlB9oDX/BfujmNOtYtcjPkwqUw/xWlfmUCAJR5t/8ztGnX h0lLtTMfj7ubqK+GYmTs/w/86rMy2iIK/c5JCMEhtejVqamTi1jNytmEAEUmHzKHrrB0 810CZCr0H1zqceM0ksm0gHJyHpsFtUhBKXvTv9B9W+2NN8FULgsug7/niU4gyLTHqlEH uj6Q== X-Gm-Message-State: AODbwcBpzRQZcSL/lLePywRAbCX2u+zGwPPdbELl3K83/pCpgIwolqub lL3gqCERVXsSIBlQllFfEywv/qrFBQ== X-Received: by 10.80.165.133 with SMTP id a5mr20901371edc.53.1496899938318; Wed, 07 Jun 2017 22:32:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.170.19 with HTTP; Wed, 7 Jun 2017 22:32:17 -0700 (PDT) In-Reply-To: <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> From: Tal Mizrahi Date: Thu, 8 Jun 2017 08:32:17 +0300 Message-ID: To: "Brian Trammell (IETF)" Cc: "ippm@ietf.org" Content-Type: multipart/alternative; boundary="f403045c28d0167e6c05516c2de0" Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jun 2017 05:32:22 -0000 --f403045c28d0167e6c05516c2de0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As a coauthor, I support the adoption of this draft, I support adding it to the charter, and I am committed to take part in editing the document based on the working group feedback. Cheers, Tal. On Tue, May 30, 2017 at 11:17 AM, Brian Trammell (IETF) wrote: > Greetings, IPPM, > > At our Chicago meeting, we decided we needed a single, cleaned-up documen= t > containing appropriate scoping and rationale in order to make a decision = as > to whether we'd like to adopt IOAM within IPPM. This revision of > draft-brockners-inband-oam-data is that document. > > This message, therefore, starts a call for adoption on > draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday > 20 June 2017. Please reply to ippm@ietf.org indicating: > > (1) whether you support addition of the following milestone to the IPPM > charter: > > date TBD: Submit an Experimental draft on inband OAM based measurement > methodologies to the IESG > > (2) whether you support the adoption of draft-brockners-inband-oam-data-0= 5 > as the basis document for this milestone > > (3) whether you commit to reviewing the document if adopted > > > We are aware that there is an open question as to whether we can adopt > draft-brockners-inband-oam-data under our current charter; we'd like to > see if there is IPPM WG consensus on adoption before discussing a > recharter, hopefully before Prague, though we can take face-to-face time = in > Prague for this if necessary. Our intention, as chairs, is to make the > minimal necessary change to the charter should there be consensus for > adoption. However, if you have particular opinions as to how this should = be > done, please also address these in your message. > > Many thanks, best regards, > > Brian (as IPPM co-chair) > > > > > On 29 May 2017, at 17:26, Frank Brockners (fbrockne) > wrote: > > > > Dear IPPM WG, > > > > we=E2=80=99ve just posted an updated version of draft-brockners-inband-= oam-data: > https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is > to address the recent comments on the mailing list. The main change is th= e > verbiage around the need to ensure that IOAM data is kept within the IOAM > domain. In addition, several editorial nits have been cleaned up. > > > > We appreciate your thoughts and comments. > > > > Regards, Frank > > > > _______________________________________________ > > 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 > > --f403045c28d0167e6c05516c2de0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a coauthor, I support the adoption of this draft, I sup= port adding it to the charter, and I am committed to take part in editing t= he document based on the working group feedback.

Cheers,=
Tal.

On Tue, May 30, 2017 at 11:17 AM, Brian Trammell (IETF) <ietf@tra= mmell.ch> wrote:
Greeting= s, IPPM,

At our Chicago meeting, we decided we needed a single, cleaned-up document = containing appropriate scoping and rationale in order to make a decision as= to whether we'd like to adopt IOAM within IPPM. This revision of draft= -brockners-inband-oam-data is that document.

This message, therefore, starts a call for adoption on draft-brockners-inba= nd-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Plea= se reply to ippm@ietf.org indicating:<= br>
(1) whether you support addition of the following milestone to the IPPM cha= rter:

date TBD: Submit an Experimental draft on inband OAM based measurement meth= odologies to the IESG

(2) whether you support the adoption of draft-brockners-inband-oam-dat= a-05 as the basis document for this milestone

(3) whether you commit to reviewing the document if adopted


We are aware that there is an open question as to whether we can adopt draf= t-brockners-inband-oam-data under our current charter; we'd like t= o see if there is IPPM WG consensus on adoption before discussing a rechart= er, hopefully before Prague, though we can take face-to-face time in Prague= for this if necessary. Our intention, as chairs, is to make the minimal ne= cessary change to the charter should there be consensus for adoption. Howev= er, if you have particular opinions as to how this should be done, please a= lso address these in your message.

Many thanks, best regards,

Brian (as IPPM co-chair)



> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <fbrockne@cisco.com> wrote:
>
> Dear IPPM WG,
>
> we=E2=80=99ve just posted an updated version of draft-brockners-inband= -oam-data: https://tools.ietf.org= /html/draft-brockners-inband-oam-data-05 which is to address = the recent comments on the mailing list. The main change is the verbiage ar= ound the need to ensure that IOAM data is kept within the IOAM domain. In a= ddition, several editorial nits have been cleaned up.
>
> We appreciate your thoughts and comments.
>
> Regards, Frank
>
> _______________________________________________
> 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


--f403045c28d0167e6c05516c2de0-- From nobody Thu Jun 8 06:49:10 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E7C129B63; Thu, 8 Jun 2017 06:49:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149692974263.14696.1265969079877701381@ietfa.amsl.com> Date: Thu, 08 Jun 2017 06:49:02 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-6man-pdm-option-12.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 13:49:03 -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 of the IETF. Title : IPv6 Performance and Diagnostic Metrics (PDM) Destination Option Authors : Nalini Elkins Robert M. Hamilton Michael S. Ackermann Filename : draft-ietf-ippm-6man-pdm-option-12.txt Pages : 30 Date : 2017-06-08 Abstract: To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-12 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-6man-pdm-option-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-6man-pdm-option-12 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 Jun 8 06:55:46 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D82126BF6; Thu, 8 Jun 2017 06:55:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, Al Morton , Bill Cerveny , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149693014458.14716.408700063358565682.idtracker@ietfa.amsl.com> Date: Thu, 08 Jun 2017 06:55:44 -0700 Archived-At: Subject: [ippm] Suresh Krishnan's No Objection on draft-ietf-ippm-6man-pdm-option-12: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 13:55:45 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS points and my comments. From nobody Thu Jun 8 07:05:05 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AED8129B63 for ; Thu, 8 Jun 2017 07:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.41 X-Spam-Level: X-Spam-Status: No, score=0.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 KovEw9pP2W0T for ; Thu, 8 Jun 2017 07:05:01 -0700 (PDT) Received: from sonic315-16.consmr.mail.gq1.yahoo.com (sonic315-16.consmr.mail.gq1.yahoo.com [98.137.65.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63AC8126C3D for ; Thu, 8 Jun 2017 07:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1496930701; bh=by7RNpN3ef0kPzRtsacSXAGd828nBDfiRm3M66FgOnU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Ha0YPowgf+qKfKBC/MKyqluWkbW0OTrLzyW6Kf+kid2fnJ1YIICb4AIOHp3q2fgbNNmWeqMugGuM51n6dhGQ3PjnfXS4yZUm6wcyrPd9jBzt3H5VjeYAYMgvURyG1LwU71M7AKm+Ny+U9q53YMffJ6TmYwCU9gGvklV30QMxPPEzmNuyCM1qC5oDp406pWq5qWtEJL0k/LdteK8CYxRreG+FFBtcVyR1gviOkmrSCLpv4L6J5xkbo8nL+vojVc/ft4ekN+08VlL0Btj/YQzaJTNU6H2lREAEcqKTE3qkDeHqQhQSGesUPAETRwsY/ldb21rCqh3umGvEkhzkizz65Q== X-YMail-OSG: QIp1BbYVM1niEmE6dAkuCz0glmJCFNLTv5QVnbDaluVj3_S5ymOqxsrFE8mfacf NKi1e2JiFLd0rQ9G7nJTtzrAZiC9it4rLugqCxCCjtsNpIXrWF3Hp.jCr5SQ3F9eivlY2ihvcfVn uvcYpnbTYyRJ7vVO3VgBBNNL7w.96It8Y6_yYn0Q_gF6ES6Yy7OrG5olNW6TnH5.AbPumTNM.i4w YRB_nVPq2BDFN1n08MTRVIqMMhWNTvIAMF0OJxrqLMt62bfGKX.Qe9YK7VotVMM2GDHhuCByh.NW DNX.0I.ZSwsg.MHJGdAjOkpm7sK.jDKjPRfNyli2AtHRMEkXyl73wxw3bHY6y6ehDHfbw5TbtkjC Kjw9cnbFaNclBzTzQTTwpT6SmTRVv3px_VPajDJhIe5SuYceszjgJhyrWCe6oBJPhyfuo_S6Hu38 EjtFC7BewRpFQnF_jmvuVNk.wKdUFN9NadHmdyUXrxsmv7Mi0yRgjKjgOakiPi2diOUFXd8guh4Q JK_Ysl0MbOQmsxw0gN0aHT5J45wIb4RprIdTJO2Ea3rojRqpIvYkE5flzu8zA47WZEMCS4RBZZRZ 3vQluvuRhBFzmhqALrinkndOuuGvcBBl4xAUUUHPPVoq5aUUqwBzy0A9OKw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 8 Jun 2017 14:05:01 +0000 Date: Thu, 8 Jun 2017 13:54:59 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Suresh Krishnan Cc: The IESG , "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , Al Morton , "ippm@ietf.org" Message-ID: <315362574.6218736.1496930099287@mail.yahoo.com> In-Reply-To: <52AB50CD-9412-4551-A8C8-461504D58041@gmail.com> References: <1081965272.4091641.1496769081453.ref@mail.yahoo.com> <1081965272.4091641.1496769081453@mail.yahoo.com> <1071027365.4388609.1496781868310@mail.yahoo.com> <52AB50CD-9412-4551-A8C8-461504D58041@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6218735_774094658.1496930099284" X-Mailer: WebService/1.1.9778 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Archived-At: Subject: [ippm] draft-ietf-ippm-6man-pdm-option-12 [ was Re: draft-ietf-ippm-6man-pdm-option-11] X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jun 2017 14:05:03 -0000 ------=_Part_6218735_774094658.1496930099284 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, We have posted a new draft with the change agreed to by Suresh. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/=C2=A0 =C2= =A0 Please let me know if anyone else has any comments.=C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Suresh Krishnan To: Nalini J Elkins =20 Cc: The IESG ; "draft-ietf-ippm-6man-pdm-option@ietf.org" ; Bill Cerveny = ; "ippm-chairs@ietf.org" ; Al Morton ; "ippm@ietf.org" Sent: Wednesday, June 7, 2017 11:36 AM Subject: Re: draft-ietf-ippm-6man-pdm-option-11 =20 Hi Nalini, On Jun 7, 2017, at 2:14 AM, Nalini J Elkins wrote: Suresh, >=C2=A0I looked over the new version and it has fixed 3 out of the 4 points= I brought up (Thanks!). The alignment one still remains unaddressed. I tho= ught we=C2=A0 > agreed to an alignment requirement of 2n but the draft just says > "The alignment for PDM is per RFC2460 [RFC2460]=E2=80=9D > which really says nothing since RFC2460 expects *this* document to state = the alignment requirement. I looked at a number of the other RFCs which define Destination Options. = =C2=A0RFC6275 : Mobility Support in IPv6, Section 6.2.1 has: "Mobility options may have alignment requirements. Following the=C2=A0conve= ntion in IPv6, these options are aligned in a packet so that multi-octet va= lues within the Option Data field of each option fall on natural boundaries= (i.e., fields of width n octets are placed at an integer multiple of n oct= ets from the start of the header, for n =3D 1, 2, 4, or 8) [6]" If we use the same wording: OLD----"The alignment for PDM is per RFC2460 [RFC2460]=E2=80=9D New---"PDM has alignment requirements. Following the convention in IPv6, th= ese options are aligned in a packet so that multi-octet values within the O= ption Data field of each option fall on natural boundaries (i.e., fields of= width n octets are placed at an integer multiple of n octets from the star= t of the header, for n =3D 1, 2, 4, or 8) [RFC2460]"=C2=A0 =C2=A0Please let me know if you are OK with the changes and I will create a= new version. Looks good to me. ThanksSuresh =20 ------=_Part_6218735_774094658.1496930099284 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

We have posted a new d= raft with the change agreed to by Suresh.

The IETF datatracker status p= age for this draft is:

<= div dir=3D"ltr" style=3D"margin: 0px; padding: 0px; line-height: 1.2em; zoo= m: 1; font-family: Helvetica, Arial, sans-serif; font-size: 13px;" id=3D"yu= i_3_16_0_1_1496929943891_5746">
Pl= ease let me know if anyone else has any comments.
 
Thanks,

Nalini Elkins
CEO a= nd Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-= 8360


From: Suresh Krishnan &l= t;suresh.krishnan@gmail.com>
T= o: Nalini J Elkins <nalini.elkins@insidethestack.com>
= Cc: The IESG <iesg@ietf= .org>; "draft-ietf-ippm-6man-pdm-option@ietf.org" <draft-ietf-ippm-6m= an-pdm-option@ietf.org>; Bill Cerveny <ietf@wjcerveny.com>; "ippm-= chairs@ietf.org" <ippm-chairs@ietf.org>; Al Morton <acmorton@att.c= om>; "ippm@ietf.org" <ippm@ietf.org>
Sent: Wednesday, June 7, 2017 11:36 AM
Subject: Re: draft-ietf-ippm-6man-= pdm-option-11

Hi Nalini,

On Jun 7, 2017, at 2:14 AM= , Nalini J Elkins <nalini.elkins@insidethest= ack.com> wrote:

Suresh,

> I looked over the new version and it has fixed 3 out of the= 4 points I brought up (Thanks!). The alignment one still remains unaddress= ed. I thought we 
> agree= d to an alignment requirement of 2n but the draft just says

> = "The alignment for PDM is per RFC2460 [RFC2460]=E2=80=9D

&g= t; which really says nothing since RFC2460 expects *this* document to state= the alignment requirement.



I looked at a number of the other RFCs = which define Destination Options.  RFC6275 : Mobility Support in IPv6,= Section 6.2.1 has:

"Mobility options may have alignment re= quirements. Following the convention in IPv6, these options are align= ed in a packet so that multi-octet values within the Option Data field of e= ach option fall on natural boundaries (i.e., fields of width n octets are p= laced at an integer multiple of n octets from the start of the header, for = n =3D 1, 2, 4, or 8) [6]"


If we use= the same wording:

OLD
----
"Th= e alignment for PDM is per RFC2460 [RFC2460]=E2=80=9D

New<= /div>
---
"PDM has alignment requirements= . Following the convention in IPv6, these options are aligned in a packet s= o that multi-octet values within the Option Data field of each option fall = on natural boundaries (i.e., fields of width n octets are placed at an inte= ger multiple of n octets from the start of the header, for n =3D 1, 2, 4, o= r 8) [RFC2460]" 


 Please let me k= now if you are OK with the changes and I will create a new version.

Looks good to me.

Thanks
Suresh



=
------=_Part_6218735_774094658.1496930099284-- From nobody Thu Jun 8 15:05:36 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50624129AF4; Thu, 8 Jun 2017 15:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fyj-CgdSGIm4; Thu, 8 Jun 2017 15:05:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8459129AC9; Thu, 8 Jun 2017 15:05:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 69A03B814C9; Thu, 8 Jun 2017 15:05:11 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ippm@ietf.org Message-Id: <20170608220511.69A03B814C9@rfc-editor.org> Date: Thu, 8 Jun 2017 15:05:11 -0700 (PDT) Archived-At: Subject: [ippm] RFC 8186 on Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jun 2017 22:05:23 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8186 Title: Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP) Author: G. Mirsky, I. Meilik Status: Standards Track Stream: IETF Date: June 2017 Mailbox: gregimirsky@gmail.com, israel@broadcom.com Pages: 8 Characters: 17818 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ippm-twamp-time-format-06.txt URL: https://www.rfc-editor.org/info/rfc8186 DOI: 10.17487/RFC8186 This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to the Network Time Protocol that is currently used. This document is a product of the IP Performance Metrics Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jun 8 19:13:00 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B728D129329 for ; Thu, 8 Jun 2017 19:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 yZiC5FXNE4vY for ; Thu, 8 Jun 2017 19:12:56 -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 8134A126BF0 for ; Thu, 8 Jun 2017 19:12:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIE06871; Fri, 09 Jun 2017 02:12:53 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 9 Jun 2017 03:12:51 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 9 Jun 2017 10:12:48 +0800 From: Tianran Zhou To: "Brian Trammell (IETF)" , "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for draft-brockners-inband-oam-data Thread-Index: AQHS2R1Edq1BcGskMke/ShX4ICXfg6Ib2Cwg Date: Fri, 9 Jun 2017 02:12:47 +0000 Message-ID: References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> In-Reply-To: <5D244444-2A45-474D-928E-EA18B206DA5D@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.156.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.593A0425.019A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7adfca80bc992bf9bca3c4d9ab4f1024 Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jun 2017 02:12:59 -0000 SGkgQWxsLA0KDQpJIGhhdmUgcmVhZCBhbGwgdGhlIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2Ft LSoqIHNlcmllcy4gSSBzdXBwb3J0IHRoZSBhZG9wdGlvbi4NCkkgd291bGQgbGlrZSB0byByZXZp ZXcgdGhlIGRvY3VtZW50cyBpZiBhZG9wdGVkLg0KDQpDaGVlcnMsDQpUaWFucmFuDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIFRyYW1tZWxsIChJRVRGKQ0KPiBTZW50OiBU dWVzZGF5LCBNYXkgMzAsIDIwMTcgNDoxOCBQTQ0KPiBUbzogaXBwbUBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBbaXBwbV0gQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0t ZGF0YQ0KPiANCj4gR3JlZXRpbmdzLCBJUFBNLA0KPiANCj4gQXQgb3VyIENoaWNhZ28gbWVldGlu Zywgd2UgZGVjaWRlZCB3ZSBuZWVkZWQgYSBzaW5nbGUsIGNsZWFuZWQtdXAgZG9jdW1lbnQNCj4g Y29udGFpbmluZyBhcHByb3ByaWF0ZSBzY29waW5nIGFuZCByYXRpb25hbGUgaW4gb3JkZXIgdG8g bWFrZSBhIGRlY2lzaW9uDQo+IGFzIHRvIHdoZXRoZXIgd2UnZCBsaWtlIHRvIGFkb3B0IElPQU0g d2l0aGluIElQUE0uIFRoaXMgcmV2aXNpb24gb2YNCj4gZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1v YW0tZGF0YSBpcyB0aGF0IGRvY3VtZW50Lg0KPiANCj4gVGhpcyBtZXNzYWdlLCB0aGVyZWZvcmUs IHN0YXJ0cyBhIGNhbGwgZm9yIGFkb3B0aW9uIG9uDQo+IGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQt b2FtLWRhdGEsIHRvIHJ1biB1bnRpbCBFT0IgQ0VTVCAoVVRDICsyKSBUdWVzZGF5DQo+IDIwIEp1 bmUgMjAxNy4gUGxlYXNlIHJlcGx5IHRvIGlwcG1AaWV0Zi5vcmcgaW5kaWNhdGluZzoNCj4gDQo+ ICgxKSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkZGl0aW9uIG9mIHRoZSBmb2xsb3dpbmcgbWlsZXN0 b25lIHRvIHRoZSBJUFBNDQo+IGNoYXJ0ZXI6DQo+IA0KPiBkYXRlIFRCRDogU3VibWl0IGFuIEV4 cGVyaW1lbnRhbCBkcmFmdCBvbiBpbmJhbmQgT0FNIGJhc2VkIG1lYXN1cmVtZW50DQo+IG1ldGhv ZG9sb2dpZXMgdG8gdGhlIElFU0cNCj4gDQo+ICgyKSB3aGV0aGVyIHlvdSBzdXBwb3J0IHRoZSBh ZG9wdGlvbiBvZiBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhLTA1DQo+IGFzIHRoZSBi YXNpcyBkb2N1bWVudCBmb3IgdGhpcyBtaWxlc3RvbmUNCj4gDQo+ICgzKSB3aGV0aGVyIHlvdSBj b21taXQgdG8gcmV2aWV3aW5nIHRoZSBkb2N1bWVudCBpZiBhZG9wdGVkDQo+IA0KPiANCj4gV2Ug YXJlIGF3YXJlIHRoYXQgdGhlcmUgaXMgYW4gb3BlbiBxdWVzdGlvbiBhcyB0byB3aGV0aGVyIHdl IGNhbiBhZG9wdA0KPiBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhIHVuZGVyIG91ciBj dXJyZW50IGNoYXJ0ZXI7IHdlJ2QgbGlrZSB0bw0KPiBzZWUgaWYgdGhlcmUgaXMgSVBQTSBXRyBj b25zZW5zdXMgb24gYWRvcHRpb24gYmVmb3JlIGRpc2N1c3NpbmcgYSByZWNoYXJ0ZXIsDQo+IGhv cGVmdWxseSBiZWZvcmUgUHJhZ3VlLCB0aG91Z2ggd2UgY2FuIHRha2UgZmFjZS10by1mYWNlIHRp bWUgaW4gUHJhZ3VlDQo+IGZvciB0aGlzIGlmIG5lY2Vzc2FyeS4gT3VyIGludGVudGlvbiwgYXMg Y2hhaXJzLCBpcyB0byBtYWtlIHRoZSBtaW5pbWFsDQo+IG5lY2Vzc2FyeSBjaGFuZ2UgdG8gdGhl IGNoYXJ0ZXIgc2hvdWxkIHRoZXJlIGJlIGNvbnNlbnN1cyBmb3IgYWRvcHRpb24uDQo+IEhvd2V2 ZXIsIGlmIHlvdSBoYXZlIHBhcnRpY3VsYXIgb3BpbmlvbnMgYXMgdG8gaG93IHRoaXMgc2hvdWxk IGJlIGRvbmUsDQo+IHBsZWFzZSBhbHNvIGFkZHJlc3MgdGhlc2UgaW4geW91ciBtZXNzYWdlLg0K PiANCj4gTWFueSB0aGFua3MsIGJlc3QgcmVnYXJkcywNCj4gDQo+IEJyaWFuIChhcyBJUFBNIGNv LWNoYWlyKQ0KPiANCj4gDQo+IA0KPiA+IE9uIDI5IE1heSAyMDE3LCBhdCAxNzoyNiwgRnJhbmsg QnJvY2tuZXJzIChmYnJvY2tuZSkgPGZicm9ja25lQGNpc2NvLmNvbT4NCj4gd3JvdGU6DQo+ID4N Cj4gPiBEZWFyIElQUE0gV0csDQo+ID4NCj4gPiB3ZeKAmXZlIGp1c3QgcG9zdGVkIGFuIHVwZGF0 ZWQgdmVyc2lvbiBvZiBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhOg0KPiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS0wNSB3 aGljaCBpcw0KPiB0byBhZGRyZXNzIHRoZSByZWNlbnQgY29tbWVudHMgb24gdGhlIG1haWxpbmcg bGlzdC4gVGhlIG1haW4gY2hhbmdlIGlzIHRoZQ0KPiB2ZXJiaWFnZSBhcm91bmQgdGhlIG5lZWQg dG8gZW5zdXJlIHRoYXQgSU9BTSBkYXRhIGlzIGtlcHQgd2l0aGluIHRoZSBJT0FNDQo+IGRvbWFp bi4gSW4gYWRkaXRpb24sIHNldmVyYWwgZWRpdG9yaWFsIG5pdHMgaGF2ZSBiZWVuIGNsZWFuZWQg dXAuDQo+ID4NCj4gPiBXZSBhcHByZWNpYXRlIHlvdXIgdGhvdWdodHMgYW5kIGNvbW1lbnRzLg0K PiA+DQo+ID4gUmVnYXJkcywgRnJhbmsNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gaXBwbSBtYWlsaW5nIGxpc3QNCj4gPiBpcHBt QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBt DQoNCg== From nobody Thu Jun 8 19:44:26 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9391242F7 for ; Thu, 8 Jun 2017 19:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.41 X-Spam-Level: X-Spam-Status: No, score=0.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 RN1oxVZI4DQQ for ; Thu, 8 Jun 2017 19:44:23 -0700 (PDT) Received: from sonic315-17.consmr.mail.gq1.yahoo.com (sonic315-17.consmr.mail.gq1.yahoo.com [98.137.65.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0371200F3 for ; Thu, 8 Jun 2017 19:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1496976263; bh=3GNMtCGSLgOIq5nIOwQLmlNW0doQm9ipyWFa/M3+Evk=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=beom+EzXTxuo+dvjlpUm0g4b2djD8zJFUWlO7WtXRPOyZojPJxdWjp4HJyekUPvuzbAj/LDwqXQEoPTq7slkdPcwc9JakHHfQ5LZCibznS/3uOjzVQie0F99opf8MTLoxD++pSRSXPooIKUQBl0fSicBhu6vCmm8zFNBMloFP0C9ngl+7+0NV0naIrdpGZ5rULXi4aUqP+hJGp2oUUFXxgcdSefo6iQ5/VBls6Eh29b+WiTpKkMozpudjy65Hf9HH0QMPGcCRVgFoqgYPgZUtSASUb2nn2IM6b63cVBNsdaTQwj3cxhGvx02SIfYok8BL3pSxb34B3je1RI1VZu7gA== X-YMail-OSG: zb_7Zq8VM1kg23BRTQy1wc8N0vnE5d7LmBGHnF4ykjcKvQWdeVZi2GTECEJPxtj 8miV_wailCwciOJE2hmpnh_GzshvcAADaFa.D_kNuJRMJqnlNbQ0gAKsmwzvQ_IC7a0eCjJQB9YI hZGQPEi.dSVKKgUtjICLXFER_jEn8H16qomaGI9bS85Gmrag4dwX29bgdH.FElh7DzbUAf.PVlh. cyrjbOedQSgyQwE7qbLDweUlqBsIYpOLsVaEt6UWz171NPVSu9a8mPICBD4iUC3zAfypY24MBcZi I3HLel0wMICWuMJHMG_fgW59Qp1oBHbM6T1NbjpBDYmuaUZJU0Sfeqw9vq38ZMTLZbWObxAaYsG9 xDQ8WqGndEUnZzQE8MI7vXeH.cuHgvJ7akxn41Z.aKms_gQ958xN22q9sy0b4Ctr.vNszqTdNsgM B6LmyXEClcR4AIP4GnEwqjKSuDlWx0dKOv3DDDq0oQmft_VkTE.3RIQlbAHBRiW5OtGFUzsOdBmH Pq1TxdfWUUH1OfU5s4mdWuQPAScp4ukENBUR7MIiScZlby3fAgzE_Mli_m7c3riOQG_x0jJF0G5W p18lo9CNWdx_DlTxAHDgP Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Jun 2017 02:44:23 +0000 Date: Fri, 9 Jun 2017 02:44:22 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: "Brian Trammell (IETF)" , "ippm@ietf.org" Message-ID: <1473481712.6917616.1496976262872@mail.yahoo.com> In-Reply-To: <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.9778 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jun 2017 02:44:25 -0000 All, >1) whether you support addition of the following milestone to the IPPM cha= rter: > date TBD: Submit an Experimental draft on inband OAM based measurement me= thodologies to the IESG I support addition of this milestone. =20 > (2) whether you support the adoption of draft-brockners-inband-oam-data-0= 5 as the basis document for this milestone Yes. But, I have some comments as to the various data fields most of which= I will save for the actual discussion of the draft. For example, we may = be able to compress the number of fields. I also need to think a bit more about time= synchronization issues as well as the granularity of the timestamps.=20 > (3) whether you commit to reviewing the document if adopted Yes. I commit to reviewing the document. I have provided some comments t= o the authors in early versions of the document. I found the other docume= nts in this series helpful in=20 understanding the data layout so it may be good to have pointers to them, p= ossibly as white papers. =20 Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Brian Trammell (IETF) To: "ippm@ietf.org" =20 Sent: Tuesday, May 30, 2017 1:17 AM Subject: [ippm] Adoption call for draft-brockners-inband-oam-data Greetings, IPPM, At our Chicago meeting, we decided we needed a single, cleaned-up document = containing appropriate scoping and rationale in order to make a decision as= to whether we'd like to adopt IOAM within IPPM. This revision of draft-bro= ckners-inband-oam-data is that document. This message, therefore, starts a call for adoption on draft-brockners-inba= nd-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please re= ply to ippm@ietf.org indicating: (1) whether you support addition of the following milestone to the IPPM cha= rter: date TBD: Submit an Experimental draft on inband OAM based measurement meth= odologies to the IESG (2) whether you support the adoption of draft-brockners-inband-oam-data-05 = as the basis document for this milestone (3) whether you commit to reviewing the document if adopted We are aware that there is an open question as to whether we can adopt draf= t-brockners-inband-oam-data under our current charter; we'd like to see if = there is IPPM WG consensus on adoption before discussing a recharter, hopef= ully before Prague, though we can take face-to-face time in Prague for this= if necessary. Our intention, as chairs, is to make the minimal necessary c= hange to the charter should there be consensus for adoption. However, if yo= u have particular opinions as to how this should be done, please also addre= ss these in your message. Many thanks, best regards, Brian (as IPPM co-chair) > On 29 May 2017, at 17:26, Frank Brockners (fbrockne) = wrote: >=20 > Dear IPPM WG, >=20 > we=E2=80=99ve just posted an updated version of draft-brockners-inband-oa= m-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 whic= h is to address the recent comments on the mailing list. The main change is= the verbiage around the need to ensure that IOAM data is kept within the I= OAM domain. In addition, several editorial nits have been cleaned up. >=20 > We appreciate your thoughts and comments. >=20 > Regards, Frank >=20 > _______________________________________________ > 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 From nobody Fri Jun 9 03:14:11 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2F612957A for ; Fri, 9 Jun 2017 03:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4DDIxSrSDOtz for ; Fri, 9 Jun 2017 03:14:08 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01DB81294B2 for ; Fri, 9 Jun 2017 03:14:07 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id p189so27940155lfe.2 for ; Fri, 09 Jun 2017 03:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yYKtr02AdBfn8Nz/rngp4v2PvBxQRhLQKY1j6JRLAlY=; b=O/623qCcgoHNL0bO1fmCx/eApAAQP91sL5wfRK0ToCctOjIiQ0EP5QVrWwCec98ct9 nqCDpNYV51io6YkDauvokGrf8MJp6DobuSDNMtPVNNoodYPyu6f/Gj8tnrVSRlcdHWLI EPP2srqcaUGKyyctIwSM7FvwdzA08oEbO8s/YVsTUGPtuQ1krE6IT5MCWfsVS6+ElPMO xn4GHkH63daW+mxsO4QS9Lr24BEJUBC5oiPlyiIOnpah8p4qiHkjF5nt8oRE88TToSil +vgqSbMtT9j5Y944Ehc6SomvH5mgs+jzXUVr+okZuTKWWOguoxx+pBmrRzWVE/j8+AQj jiYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yYKtr02AdBfn8Nz/rngp4v2PvBxQRhLQKY1j6JRLAlY=; b=mIw19P5YWZp4BTx274v9io3qL3esiNxCtLVI2f2kobwJIR3iLKuJK+HQoVaTYFPS/2 S+JJzYdn2QxVr2KMOkuxmAI9m6+u29UwEAcUb+Havr5CF60psfndf9lWSFA37UhXD8wh 92pWc0XL/8XPj04MOypeQbKA2lXBgCkp3aP3D9AoUlcrtphWhs0kV5RlLNll4x9n0DPz Pye9YZfXw7qrJ82T/KQloCrz668X0yp79SmepN2TvUqmwLahBBx69y8iTxmRIFnwP+zK MgJFS+Qvyfr0I4m2gNv50yN4kr4noOdjnYrkZzzhmhFitMETOJUW9OW3Nem1XfguUNxG 9x1w== X-Gm-Message-State: AODbwcDbhCJv2L/zUnM529X1Z8Ufcy9ym7V0XtYzzlzU7tY30L5KW727 u+rGV7TmfJJzCDGmu9p7pbTXqA3mZg== X-Received: by 10.25.22.206 with SMTP id 75mr3234223lfw.158.1497003246222; Fri, 09 Jun 2017 03:14:06 -0700 (PDT) MIME-Version: 1.0 References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> In-Reply-To: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> From: Praveen Ananthasankaran Date: Fri, 09 Jun 2017 10:13:55 +0000 Message-ID: To: "Brian Trammell (IETF)" , IETF IPPM WG Content-Type: multipart/alternative; boundary="001a11406b6cb801b60551843a1b" Archived-At: Subject: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jun 2017 10:14:11 -0000 --001a11406b6cb801b60551843a1b Content-Type: text/plain; charset="UTF-8" Hi All, I believe the document is ready for publication. Its a useful technology for performance metrics measurement. Thanks, Praveen On Tue, May 30, 2017 at 9:23 PM Brian Trammell (IETF) wrote: > Greetings, IPPM, > > As discussed in Chicago, this message begins a Working Group Last Call on > draft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday 20 > June 2017. Please reply to ippm@ietf.org indicating whether you believe > this document is ready for publication, and if not, why not. > > Many thanks, best regards, > > Brian (as IPPM co-chair) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --001a11406b6cb801b60551843a1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I believe the documen= t is ready for publication.
Its a useful technology for performance met= rics measurement.

Thanks,
Praveen
=

On Tue, May 30, 2017 a= t 9:23 PM Brian Trammell (IETF) <iet= f@trammell.ch> wrote:
Greeti= ngs, IPPM,

As discussed in Chicago, this message begins a Working Group Last Call on d= raft-ietf-ippm-alt-mark, to=C2=A0 to run until EOB CEST (UTC +2) Tuesday 20= June 2017. Please reply to ippm@ietf.org indicating whether you believe this document is ready= for publication, and if not, why not.

Many thanks, best regards,

Brian (as IPPM co-chair)
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--001a11406b6cb801b60551843a1b-- From nobody Fri Jun 9 08:39:56 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26A1129B5E for ; Fri, 9 Jun 2017 08:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.com 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 sTDyNmxQlH5Q for ; Fri, 9 Jun 2017 08:39:50 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 F411F12946B for ; Fri, 9 Jun 2017 08:39:49 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id F02F01C18F8 for ; Fri, 9 Jun 2017 10:39:48 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 6311F1C18BD; Fri, 9 Jun 2017 10:39:48 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2E521FE069; Fri, 9 Jun 2017 11:39:48 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0F7B8FE063; Fri, 9 Jun 2017 11:39:48 -0400 (EDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (unknown [207.46.163.82]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Fri, 9 Jun 2017 11:39:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2eWg7Luls5OPow/Snbtk80kptUSFYWmUjnXR31OJZQk=; b=1J1CQeeYxNTTMjGXJ9md4Xn/GhTeVXyxMGhUb4A9g0BDHBy/ONC6Gx1WoesIvecSFbBBtt6q1kPUnwWHeVANGRhattd9194kUF1dPitFVj3qILkEuCe+QpQbz5EJ41vM7Q+pdMjMW0iGeNNW1qaxB3liQXXezvOZ+pke6T7YLc8= Received: from BN6PR14MB1361.namprd14.prod.outlook.com (10.172.149.135) by BN6PR14MB1361.namprd14.prod.outlook.com (10.172.149.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Fri, 9 Jun 2017 15:39:46 +0000 Received: from BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) by BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) with mapi id 15.01.1157.014; Fri, 9 Jun 2017 15:39:46 +0000 From: "Ackermann, Michael" To: Nalini J Elkins , "Brian Trammell (IETF)" , "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for draft-brockners-inband-oam-data Thread-Index: AQHS2R0/oWndbUDMzE+l30xvgEM8OaIb4l4AgADX+cA= Date: Fri, 9 Jun 2017 15:39:46 +0000 Message-ID: References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> <1473481712.6917616.1496976262872@mail.yahoo.com> In-Reply-To: <1473481712.6917616.1496976262872@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: insidethestack.com; dkim=none (message not signed) header.d=none;insidethestack.com; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [165.225.0.71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1361; 7:pUZ4bxZPbea4d11zbsYRZxHKodhvR/cLf5HGlk8ks1MsrELEjG4y+wU06W4q7uIdVYNST/L4RLfrlAdzBkhyfBjaZd7YAdpykOMClJXhZiEiOnAS8IhS0Bm2BVNCP8zhJiB0T1KOoB+7KqrZocEkiX3BJiIjJWrnbgUaK7emoOK57yjux8IMQgMyP62QjAdKvrkOtHkeDgVonBuhjlM66Hd/JxQu2ABII44ph8u3kpDrywT1+RuvBUKivrQNoOby04N9WTQjRCziuaxuoZGbIA+vjWe0hfzO8u8MyHXKkV5Fj2MwJldbHVAF5a+WMJ/xzikDVVn6v+/2+AGoLPk6Fg==; 20:nDJ+RfiZoERmNdCH2vOAdIkJ95cX5pY0NYF7yj8IFVOrkF2okZb1FeIUG+SJanizt2f32piuhuz9HxETIwy+JQKP0v0o1YiBE6xe3BNAjyncrwyKn4JEAqbr0bAu1/0vQHjHvPvaHZrQ+nWnuKVDbaylkoYKHhB/T6aWoa++Dxw= x-ms-traffictypediagnostic: BN6PR14MB1361: x-ms-office365-filtering-correlation-id: 133d34c0-d965-4dc8-399d-08d4af4dc1c0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR14MB1361; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(95692535739014)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR14MB1361; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR14MB1361; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39840400002)(39450400003)(377454003)(13464003)(66654002)(24454002)(99286003)(6306002)(9686003)(6246003)(53936002)(7736002)(5660300001)(77096006)(76176999)(54356999)(189998001)(50986999)(6436002)(33656002)(66066001)(55016002)(15974865002)(72206003)(2501003)(966005)(6506006)(80792005)(478600001)(102836003)(3846002)(74316002)(38730400002)(305945005)(14454004)(2900100001)(53546009)(25786009)(2950100002)(86362001)(229853002)(3660700001)(3280700002)(2906002)(7696004)(8936002)(122556002)(230783001)(81166006)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1361; H:BN6PR14MB1361.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2017 15:39:46.1681 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1361 X-TM-AS-GCONF: 00 X-VPM-MSG-ID: 67b2aae0-ecfb-4141-83bb-1f3540041baa X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 52862713-8ca0-40fe-a3d6-27efb857abf6 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jun 2017 15:39:53 -0000 DQogIA0KICArMQ0KICBPbiAgYWxsIHRocmVlIHF1ZXN0aW9ucy4gDQogICANCiAgDQogTXkg YWRkaXRpb25hbCBjb21tZW50cyAgIGFyZToNCiAgVGhlcmUgYXJlIGEgZmV3IGFyY2hpdGVj dHVyYWwgYW5kDQogIHRlY2huaWNhbCBkZXRhaWxzIHRvICBiZSB3b3JrZWQgb3V0LCBidXQg dGhpcw0KIGRyYWZ0ICBwcm9wb3NlcyBjb25zdHJ1Y3RzIGFuZCAgbWV0cmljcyB0aGF0IHdv dWxkIGJlDQogdmVyeSAgdmFsdWFibGUgdG8gbmV0d29yayBhbmQgIGVudGVycHJpc2Ugb3Bl cmF0b3JzLiAgSQ0KIHdvdWxkICBsb29rICBmb3J3YXJkIHRvIHJldmlld2luZyBhbmQgYXNz aXN0aW5nIGluIGFueSB3YXkNCiBJIGNhbiAgdG8gIGFjaGlldmUgc3VjaCBhZHZhbmNlbWVu dHMgaW4gbmV0d29yaw0KIG1hbmFnZW1lbnQuICBJICBhbHNvIGZvcmVzZWUgdGhlIGluZm9y bWF0aW9uICAmDQogbWV0cmljcyB0byBiZSBkZWxpdmVyZWQgIGJ5IGluYmFuZCBPQU0sICBh cyBhIGdyZWF0DQogcGFydG5lciBhbmQgc3VwcGxlbWVudCB0byB3aGF0ICBQRE0gIHB1cnZl eXMuICBBcyBhbg0KIGVudGVycHJpc2UgIG9wZXJhdG9yLCAgSSBuZWVkIFBETSBBU0FQIGZv ciB0aGUgaGlnaCBsZXZlbA0KIHRyaWFnZSBhbmQgIGZhdWx0IGRvbWFpbiBpc29sYXRpb24g aXQgcHJvdmlkZXMuICAgIExhdGVyLA0KIChhdCBsZWFzdCBpbiAgbXkgY2hyb25vbG9naWNh bCBzZXF1ZW5jZSBvZiBwcmVmZXJlbnRpYWwNCiBldmVudHMpLCAgSSB3b3VsZCAgbGlrZSB0 byB0aGVuIHVzZSBJbmJhbmQgT0FNLCBpZiB0aGUgUERNDQogdHJpYWdlIHJlc3VsdHMgZGVl bSAgdGhvc2UgbWV0cmljcyB0byBiZSBuZWNlc3NhcnkgZmF1bHQNCiBkb21haW4gZGV0YWls cyBJIG1pZ2h0ICBuZWVkIHRvIHNvbHZlIGEgcHJvYmxlbSBvciBpbXByb3ZlDQogcGVyZm9y bWFuY2UgcXVpY2tseS4NCkxvb2sgZm9yd2FyZCB0byB3b3JraW5nIHRvZ2V0aGVyIGluIHRo aXMgIHJlZ2FyZCBhcyAgd2VsbC4gDQoNClRoYW5rcywgDQpNaWtlDQogIA0KICANCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwcG0gW21haWx0bzppcHBtLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOYWxpbmkgSiBFbGtpbnMNClNlbnQ6IFRodXJz ZGF5LCBKdW5lIDgsIDIwMTcgMTA6NDQgUE0NClRvOiBCcmlhbiBUcmFtbWVsbCAoSUVURikg PGlldGZAdHJhbW1lbGwuY2g+OyBpcHBtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2lwcG1d IEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGENCg0K QWxsLA0KDQo+MSkgd2hldGhlciB5b3Ugc3VwcG9ydCBhZGRpdGlvbiBvZiB0aGUgZm9sbG93 aW5nIG1pbGVzdG9uZSB0byB0aGUgSVBQTSBjaGFydGVyOg0KDQo+IGRhdGUgVEJEOiBTdWJt aXQgYW4gRXhwZXJpbWVudGFsIGRyYWZ0IG9uIGluYmFuZCBPQU0gYmFzZWQgbWVhc3VyZW1l bnQgbWV0aG9kb2xvZ2llcyB0byB0aGUgSUVTRw0KDQpJIHN1cHBvcnQgYWRkaXRpb24gb2Yg dGhpcyBtaWxlc3RvbmUuICAgIA0KDQoNCj4gKDIpIHdoZXRoZXIgeW91IHN1cHBvcnQgdGhl IGFkb3B0aW9uIG9mIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEtMDUgYXMgdGhl IGJhc2lzIGRvY3VtZW50IGZvciB0aGlzIG1pbGVzdG9uZQ0KDQpZZXMuICBCdXQsIEkgaGF2 ZSBzb21lIGNvbW1lbnRzIGFzIHRvIHRoZSB2YXJpb3VzIGRhdGEgZmllbGRzIG1vc3Qgb2Yg d2hpY2ggSSB3aWxsIHNhdmUgZm9yIHRoZSBhY3R1YWwgZGlzY3Vzc2lvbiBvZiB0aGUgZHJh ZnQuICAgRm9yIGV4YW1wbGUsIHdlIG1heSBiZSBhYmxlIHRvDQpjb21wcmVzcyB0aGUgbnVt YmVyIG9mIGZpZWxkcy4gICBJIGFsc28gbmVlZCB0byB0aGluayBhIGJpdCBtb3JlIGFib3V0 IHRpbWUgc3luY2hyb25pemF0aW9uIGlzc3VlcyBhcyB3ZWxsIGFzIHRoZSBncmFudWxhcml0 eSBvZiB0aGUgdGltZXN0YW1wcy4gDQoNCg0KPiAoMykgd2hldGhlciB5b3UgY29tbWl0IHRv IHJldmlld2luZyB0aGUgZG9jdW1lbnQgaWYgYWRvcHRlZA0KDQpZZXMuICAgSSBjb21taXQg dG8gcmV2aWV3aW5nIHRoZSBkb2N1bWVudC4gIEkgaGF2ZSBwcm92aWRlZCBzb21lIGNvbW1l bnRzIHRvIHRoZSBhdXRob3JzIGluIGVhcmx5IHZlcnNpb25zIG9mIHRoZSBkb2N1bWVudC4g ICBJIGZvdW5kIHRoZSBvdGhlciBkb2N1bWVudHMgaW4gdGhpcyBzZXJpZXMgaGVscGZ1bCBp biANCnVuZGVyc3RhbmRpbmcgdGhlIGRhdGEgbGF5b3V0IHNvIGl0IG1heSBiZSBnb29kIHRv IGhhdmUgcG9pbnRlcnMgdG8gdGhlbSwgcG9zc2libHkgYXMgd2hpdGUgcGFwZXJzLg0KIA0K VGhhbmtzLA0KDQpOYWxpbmkgRWxraW5zDQpDRU8gYW5kIEZvdW5kZXINCkluc2lkZSBQcm9k dWN0cywgSW5jLg0Kd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQ0KKDgzMSkgNjU5LTgzNjANCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBCcmlhbiBUcmFt bWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+DQpUbzogImlwcG1AaWV0Zi5vcmciIDxp cHBtQGlldGYub3JnPiANClNlbnQ6IFR1ZXNkYXksIE1heSAzMCwgMjAxNyAxOjE3IEFNDQpT dWJqZWN0OiBbaXBwbV0gQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtYnJvY2tuZXJzLWluYmFu ZC1vYW0tZGF0YQ0KDQoNCg0KR3JlZXRpbmdzLCBJUFBNLA0KDQpBdCBvdXIgQ2hpY2FnbyBt ZWV0aW5nLCB3ZSBkZWNpZGVkIHdlIG5lZWRlZCBhIHNpbmdsZSwgY2xlYW5lZC11cCBkb2N1 bWVudCBjb250YWluaW5nIGFwcHJvcHJpYXRlIHNjb3BpbmcgYW5kIHJhdGlvbmFsZSBpbiBv cmRlciB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hldGhlciB3ZSdkIGxpa2UgdG8gYWRv cHQgSU9BTSB3aXRoaW4gSVBQTS4gVGhpcyByZXZpc2lvbiBvZiBkcmFmdC1icm9ja25lcnMt aW5iYW5kLW9hbS1kYXRhIGlzIHRoYXQgZG9jdW1lbnQuDQoNClRoaXMgbWVzc2FnZSwgdGhl cmVmb3JlLCBzdGFydHMgYSBjYWxsIGZvciBhZG9wdGlvbiBvbiBkcmFmdC1icm9ja25lcnMt aW5iYW5kLW9hbS1kYXRhLCB0byBydW4gdW50aWwgRU9CIENFU1QgKFVUQyArMikgVHVlc2Rh eSAyMCBKdW5lIDIwMTcuIFBsZWFzZSByZXBseSB0byBpcHBtQGlldGYub3JnIGluZGljYXRp bmc6DQoNCigxKSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkZGl0aW9uIG9mIHRoZSBmb2xsb3dp bmcgbWlsZXN0b25lIHRvIHRoZSBJUFBNIGNoYXJ0ZXI6DQoNCmRhdGUgVEJEOiBTdWJtaXQg YW4gRXhwZXJpbWVudGFsIGRyYWZ0IG9uIGluYmFuZCBPQU0gYmFzZWQgbWVhc3VyZW1lbnQg bWV0aG9kb2xvZ2llcyB0byB0aGUgSUVTRw0KDQooMikgd2hldGhlciB5b3Ugc3VwcG9ydCB0 aGUgYWRvcHRpb24gb2YgZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS0wNSBhcyB0 aGUgYmFzaXMgZG9jdW1lbnQgZm9yIHRoaXMgbWlsZXN0b25lDQoNCigzKSB3aGV0aGVyIHlv dSBjb21taXQgdG8gcmV2aWV3aW5nIHRoZSBkb2N1bWVudCBpZiBhZG9wdGVkDQoNCg0KV2Ug YXJlIGF3YXJlIHRoYXQgdGhlcmUgaXMgYW4gb3BlbiBxdWVzdGlvbiBhcyB0byB3aGV0aGVy IHdlIGNhbiBhZG9wdCBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhIHVuZGVyIG91 ciBjdXJyZW50IGNoYXJ0ZXI7IHdlJ2QgbGlrZSB0byBzZWUgaWYgdGhlcmUgaXMgSVBQTSBX RyBjb25zZW5zdXMgb24gYWRvcHRpb24gYmVmb3JlIGRpc2N1c3NpbmcgYSByZWNoYXJ0ZXIs IGhvcGVmdWxseSBiZWZvcmUgUHJhZ3VlLCB0aG91Z2ggd2UgY2FuIHRha2UgZmFjZS10by1m YWNlIHRpbWUgaW4gUHJhZ3VlIGZvciB0aGlzIGlmIG5lY2Vzc2FyeS4gT3VyIGludGVudGlv biwgYXMgY2hhaXJzLCBpcyB0byBtYWtlIHRoZSBtaW5pbWFsIG5lY2Vzc2FyeSBjaGFuZ2Ug dG8gdGhlIGNoYXJ0ZXIgc2hvdWxkIHRoZXJlIGJlIGNvbnNlbnN1cyBmb3IgYWRvcHRpb24u IEhvd2V2ZXIsIGlmIHlvdSBoYXZlIHBhcnRpY3VsYXIgb3BpbmlvbnMgYXMgdG8gaG93IHRo aXMgc2hvdWxkIGJlIGRvbmUsIHBsZWFzZSBhbHNvIGFkZHJlc3MgdGhlc2UgaW4geW91ciBt ZXNzYWdlLg0KDQpNYW55IHRoYW5rcywgYmVzdCByZWdhcmRzLA0KDQpCcmlhbiAoYXMgSVBQ TSBjby1jaGFpcikNCg0KDQoNCg0KPiBPbiAyOSBNYXkgMjAxNywgYXQgMTc6MjYsIEZyYW5r IEJyb2NrbmVycyAoZmJyb2NrbmUpIDxmYnJvY2tuZUBjaXNjby5jb20+IHdyb3RlOg0KPiAN Cj4gRGVhciBJUFBNIFdHLA0KPiANCj4gd2XigJl2ZSBqdXN0IHBvc3RlZCBhbiB1cGRhdGVk IHZlcnNpb24gb2YgZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YTogaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEtMDUg d2hpY2ggaXMgdG8gYWRkcmVzcyB0aGUgcmVjZW50IGNvbW1lbnRzIG9uIHRoZSBtYWlsaW5n IGxpc3QuIFRoZSBtYWluIGNoYW5nZSBpcyB0aGUgdmVyYmlhZ2UgYXJvdW5kIHRoZSBuZWVk IHRvIGVuc3VyZSB0aGF0IElPQU0gZGF0YSBpcyBrZXB0IHdpdGhpbiB0aGUgSU9BTSBkb21h aW4uIEluIGFkZGl0aW9uLCBzZXZlcmFsIGVkaXRvcmlhbCBuaXRzIGhhdmUgYmVlbiBjbGVh bmVkIHVwLg0KPiANCj4gV2UgYXBwcmVjaWF0ZSB5b3VyIHRob3VnaHRzIGFuZCBjb21tZW50 cy4NCj4gDQo+IFJlZ2FyZHMsIEZyYW5rDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBpcHBtIG1haWxpbmcgbGlzdA0KPiBpcHBt QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBw bQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K aXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXBwbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0KCgpUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29u ZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwocykgdG8gd2hvbSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IHZpZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJp YnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkg dW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0 aG91dCBtYWtpbmcgYW55IGNvcGllcy4KIAogQmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBN aWNoaWdhbiBhbmQgQmx1ZSBDYXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2Zp dCBjb3Jwb3JhdGlvbnMgYW5kIGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBD cm9zcyBhbmQgQmx1ZSBTaGllbGQgQXNzb2NpYXRpb24uCg== From nobody Sun Jun 11 06:46:56 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88141128E19 for ; Sun, 11 Jun 2017 06:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 wrPUcbz3_4D0 for ; Sun, 11 Jun 2017 06:46:54 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7D8124D68 for ; Sun, 11 Jun 2017 06:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1750; q=dns/txt; s=iport; t=1497188814; x=1498398414; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=uj0iH3TXF2EAd4JaZQEe5tZktZR9tvQ6COvhsdWbpeI=; b=ke1vx2zi6CHoMFl7oOad13WTQwI90HnDIY5fKyTIAglV+l8K/Jhkja8g DhlTeVy0CQLdbg4ASsQ2kyAZw23maMP4L3TJkuhprrZVoCRNagMpSu8B4 X6TIHcDpB5pe6MsOuKtukGpSrTiZ8fx50+otnd/eOzbvMOGv9G/FU+3XI A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAABPST1Z/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0Hg22KGJFulgOCESELhXgCGoJnPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEhEToQCwIBCBgCAiYCAgIlCxQBEAIEARKKJAgQsHyCJotkAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWBC4VWgWArgnWEaoMSMIIxBZ4/ApNHggaFQ4o?= =?us-ascii?q?9lGsBHziBCnQVSBIBhnt2iQ+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,329,1493683200"; d="scan'208";a="438185998" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jun 2017 13:46:53 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v5BDkqtR009940 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 11 Jun 2017 13:46:53 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 11 Jun 2017 09:46:52 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Sun, 11 Jun 2017 09:46:52 -0400 From: "Mouli Chandramouli (moulchan)" To: IETF IPPM WG , "Brian Trammell (IETF)" Thread-Topic: [ippm] WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2VzoNSoXtl9Lj0WLtmtkPpceE6IYXdoAgAgBBoA= Date: Sun, 11 Jun 2017 13:46:52 +0000 Message-ID: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.34.107] Content-Type: text/plain; charset="utf-8" Content-ID: <8388859A963DD747938DBCCDE999E637@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 13:46:55 -0000 DQogICAgSGkgIEJyaWFuLA0KICAgIA0KICAgIEkgc3VwcG9ydCBXR0xDIG9mIHRoZSBkb2N1bWVu dCAuDQogICAgDQogICAgSSBoYXZlIHNvbWUgY29tbWVudHMsIGZvciBjb25zaWRlcmF0aW9uIGFz IHBhcnQgb2YgdGhpcyBXR0xDLiANCg0KICAgIFRoZSBsYW5ndWFnZSBuZWVkcyB0byBiZSB0aWdo dGVuZWQgdXAsIEkgd291bGQgaG9wZSB0aGUgR0VOLUFSVCByZXZpZXcgd291bGQgdGFrZSBjYXJl IG9mIHRoYXQuIA0KDQogICAgIElzIGNvbG9yaW5nIG9yIG1hcmtpbmcgIG9mIGEgcGFja2V0IGNv bnNpZGVyZWQgYWN0aXZlIG9mIHBhc3NpdmUgPyANCg0KDQogICBEdXJpbmcgYSAgYmxvY2sgMSwg Mywg4oCmLCBuKzEgIHNob3VsZCBiZSAgMSwgMywg4oCmLCAybisxICAgDQoNCiAgIGR1cmluZyBh IEIgYmxvY2sgKGJsb2NrcyAyLCA0IGFuZCBuKSAgc2hvdWxkIGJlICAgIDIsIDQsIOKApiwgMm4N Cg0KVGhhbmtzDQpNb3VsaQ0KICAgIA0KPiBPbiBNYXkgMzAsIDIwMTcsIGF0IDExOjUzIEFNLCBC cmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+IHdyb3RlOg0KICAgID4gDQog ICAgPiBHcmVldGluZ3MsIElQUE0sDQogICAgPiANCiAgICA+IEFzIGRpc2N1c3NlZCBpbiBDaGlj YWdvLCB0aGlzIG1lc3NhZ2UgYmVnaW5zIGEgV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gZHJh ZnQtaWV0Zi1pcHBtLWFsdC1tYXJrLCB0byAgdG8gcnVuIHVudGlsIEVPQiBDRVNUIChVVEMgKzIp IFR1ZXNkYXkgMjAgSnVuZSAyMDE3LiBQbGVhc2UgcmVwbHkgdG8gaXBwbUBpZXRmLm9yZyBpbmRp Y2F0aW5nIHdoZXRoZXIgeW91IGJlbGlldmUgdGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVi bGljYXRpb24sIGFuZCBpZiBub3QsIHdoeSBub3QuDQogICAgPiANCiAgICA+IE1hbnkgdGhhbmtz LCBiZXN0IHJlZ2FyZHMsDQogICAgPiANCiAgICA+IEJyaWFuIChhcyBJUFBNIGNvLWNoYWlyKQ0K ICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICA+IGlwcG0gbWFpbGluZyBsaXN0DQogICAgPiBpcHBtQGlldGYub3JnDQogICAgPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCiAgICANCiAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIGlwcG0gbWFpbGluZyBs aXN0DQogICAgaXBwbUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXBwbQ0KICAgIA0KDQo= From nobody Sun Jun 11 10:27:37 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DE312957B; Sun, 11 Jun 2017 10:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 h8YCFZMJcNfE; Sun, 11 Jun 2017 10:27:34 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1BD129576; Sun, 11 Jun 2017 10:27:33 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id e11so5998873oia.2; Sun, 11 Jun 2017 10:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2xY6KTAeNMh/oVjI1JwmZsshHXGeMccGVT9fkDVVaIk=; b=mchZkt39vmzz5KZhcFJkMpS3Zo8jfqyjW0X5CV53wqNfogc3zapX/8uRjFbfYGRinb 34S/CRDcDbDasPcF83NSvfqHnEvDFkvBI4Fzk0m/E2X+QOZ+99skT1J3AcZloEwNkaQx IEzxXHrjTqUXZssg3Oi6ZlW6RaIlm1vNyv16Ke0IdyCUrgBRr5BkhD30Cw/lVHW+nlDI CrGGqvJal06l9cifZoQGSnMSynxEavvPw7j9HDgFek2cCK4bWThj92jqfZneW82WcENJ 3X5eUoVAWVVjQUR6qOXLgt28S8A3YwM8kFSxE74VPBpEApssrxh3jLoB2d+81kSblBMs hK3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2xY6KTAeNMh/oVjI1JwmZsshHXGeMccGVT9fkDVVaIk=; b=F1oSZnJDhQsqwfhv+Qi5W+VMNHr/M2zv5rPwrG4Yy2UZ+aMheUbALlRC5Y8CGR3AGh mziFVzvvFTQyZkPsRenfzcU9pF5yUfKQznZOUEcqcwcqDd5zbb9YxT87y1xQuDO3DZf8 +k8VvLHSM2jrLwgVzDPQcW6c9/uXzndSsRpbJkvmRKZFF34N2V3B3riQW+ePrI58WmfT +aofxJ1BOR9bSyL/9sVMSohsIUnknIbPcC5Y/bULvNvOveO+wVzgR1T/hl1XXCdH8YRl r+pu6Kbwmr6/ZuIQzCPNy+Tuk/FdFSHODYo55VcOtEKrsib8uHhg7GMt+qMIrts2f6nk r2Gw== X-Gm-Message-State: AODbwcBnNrXgLAqjqLxkJ5MjhSXc/kCMY1orDPaynZ2rVv76o9HhJ+C8 m4rmccExVRkTMlBmKq+o5Wenw/IA/XjX X-Received: by 10.202.244.86 with SMTP id s83mr10563807oih.59.1497202052988; Sun, 11 Jun 2017 10:27:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.225 with HTTP; Sun, 11 Jun 2017 10:27:32 -0700 (PDT) In-Reply-To: References: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> From: Greg Mirsky Date: Sun, 11 Jun 2017 10:27:32 -0700 Message-ID: To: IPPM Chairs Cc: "ippm@ietf.org" Content-Type: multipart/alternative; boundary="001a11c17ca486840d0551b284da" Archived-At: Subject: [ippm] Fwd: [netmod] Important: Guidelines for YANG module authors X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 17:27:36 -0000 --001a11c17ca486840d0551b284da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, wonder how Network Management Datastore Architecture (NMDA) impacts our data models. Could we get advice, suggestions from NETMOD WG? Invite someone to our session? Add as one of topics on Sunday? Regards, Greg ---------- Forwarded message ---------- From: Alia Atlas Date: Fri, Jun 9, 2017 at 8:05 AM Subject: Fwd: [netmod] Important: Guidelines for YANG module authors To: "rtgwg@ietf.org" At IETF 98 in RTGWG, I mentioned the need for clear guidelines to handle the changes coming for structuring YANG models. This is the resulting guidance. Regards, Alia ---------- Forwarded message ---------- From: Benoit Claise Date: Fri, Jun 9, 2017 at 9:56 AM Subject: [netmod] Important: Guidelines for YANG module authors To: NETMOD Working Group Dear all, Now that the new NETMOD and NETCONF charters have been approved, it's time to think about the guidelines for YANG module authors. The Network Management Datastore Architecture (NMDA) addresses the so-called "OpState problem" that has been the subject of much discussion in the IETF. NMDA is still in development, and there will be a transition period before NMDA solutions are universally available. The NETMOD Datastore Design Team and the Routing Yang Architecture Design Team have worked with Alia and Benoit to create initial guidelines for how the NMDA, as defined in draft-ietf-netmod-revised-datastores , impacts Yang models. The draft-dsdt-nmda-guidelines individual draft was foundational in helping creating those guidelines. If you have questions or concerns on how these guidelines should apply to work of interest, please contact your WG Chairs or ADs. It is our strong recommendation, as ADs with agreement from the NETMOD WG Chairs, that models SHOULD move as quickly as possible to the NMDA. The specific approach to be taken for models being developed now and during the NMDA transition period should be based on both the expected usage and the maturity of the data model. 1. New models and models that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA-compatible. 2. Models that require immediate support for "in use" and "system created" information SHOULD be structured for NMDA. Then derived versions of these models SHOULD be created, either by hand or with suitable tools, that follow the current modeling strategies. In some cases, the non-NMDA model may be an existing model and not derived from the NMDA model. In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. The non-NMDA module names should include =E2=80=99-state=E2=80=99 appended. We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder, and all others who helped develop these guidelines. Regards, Alia Atlas, Routing AD Deborah Brungard, Routing AD Alvaro Retana, Routing AD Warren Kumari, Operations & Management AD Benoit Claise, Operations & Management AD _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --001a11c17ca486840d0551b284da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
wonder how=C2=A0Network Management Datastore Architecture (NMDA) impacts ou= r data models. Could we get advice, suggestions from NETMOD WG? Invite some= one to our session? Add as one of topics on Sunday?

Regards,
Greg

---------- Forwarded m= essage ----------
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, Jun 9, 2017 at 8:05 AM
Subject: Fwd: [netmod= ] Important: Guidelines for YANG module authors
To: "rtgwg@ietf.org" <rtgwg@ietf.org>


At IETF 98 = in RTGWG, I mentioned the need for clear guidelines to handle the changes c= oming for structuring YANG models.=C2=A0 This is the resulting guidance.=C2= =A0

Regards,
Alia

---------- Forwarded message ----------
Fro= m: Benoit Claise <bclaise@cisco.com&= gt;
Date: Fri, Jun 9, 2017 at 9:56 AM
Subject: [netmod] Import= ant: Guidelines for YANG module authors
To: NETMOD Working Group <netmod@ietf.org>

=20 =20 =20
Dear all,

Now that the new NETMOD and NETCONF charters have been approved, it's time to think about the guidelines for YANG module authors.
The Network Management Datastore Architecture (NMDA) addresses the so-called "OpState problem" that has been the subject of much discussion in the IETF. NMDA is still in development, and there will be a transition period before NMDA solutions are universally available.

The NETMOD Datastore Design Team and the Routing Yang Architecture Design Team have worked with Alia and Benoit to create initial guidelines for how the NMDA, as defined in = draft-ietf-netmod-revised-datastores, impacts Yang models. The draft-dsdt-nmda-guidelines individual draft was foundational in helping creating those guidelines.

If you have questions or concerns on how these guidelines should apply to work of interest, please contact your WG Chairs or ADs.

It is our strong recommendation, as ADs with agreement from the NETMOD WG Chairs, that models SHOULD move as quickly as possible to the NMDA. The specific approach to be taken for models being developed now and during the NMDA transition period should be based on both the expected usage and the maturity of the data model.

1. New models and models that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA-compatible.

2. Models that require immediate support for "in use" and &qu= ot;system created" information SHOULD be structured for NMDA. Then derived versions of these models SHOULD be created, either by hand or with suitable tools, that follow the current modeling strategies. In some cases, the non-NMDA model may be an existing model and not derived from the NMDA model. In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. The non-NMDA module names should include =E2=80=99-state=E2=80=99 appended.

We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder, and all others who helped develop these guidelines.

Regards,
Alia Atlas, Routing AD
Deborah Brungard, Routing AD
Alvaro Retana, Routing AD
Warren Kumari, Operations & Management AD
Benoit Claise, Operations & Management AD

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


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


--001a11c17ca486840d0551b284da-- From nobody Sun Jun 11 13:53:20 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3ABD127369; Sun, 11 Jun 2017 13:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rlVC45aSn7Jg; Sun, 11 Jun 2017 13:53:17 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2CCC1270FC; Sun, 11 Jun 2017 13:53:16 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id 15so17044850pfc.1; Sun, 11 Jun 2017 13:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=cXGUIDvxs6plTts1l1++e7skX+Glv9mmQJXhhSI4Ga8=; b=nfaMXPigbdb5T9D38xAEo4dFmZnofv+W+HDZao6I+BvXAqd81wRXp5vHn1LAz3Np2p eM/IQMxCrvL6Ov7To09QCPPNKkxhHzC/PDGw6vyFtzq67CX0v5L5KDjVlY7YiFOmN7a6 qQ2HQ5G+t+IDMgbAB8mUhgQMR07pn7xXItJs4QR6X2TKISYfCVVrm8Yuq8BlVC753Lq3 A57V2Rs9B8lguKdetTyCfKmTGm7vVK4OTvSgioXh2nEQ0ax409WLcEv6N6UhljlvJEam UI2xmf7pKGKko4nf27uuJlwvYNAgz7fG06fQII4/xjA5APSYdWUKC09yFZk8zbayYO2F WuKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cXGUIDvxs6plTts1l1++e7skX+Glv9mmQJXhhSI4Ga8=; b=iV4uwNcktNJcC9B4WQ2Jw2eWANWiwcBEJtxKiHvi9K077PiQieFDBQabWbQ/69WKzO nNLteT83FOGYlkkqvG/olQl47b2Zgo/Gxl9IM4cYfUhoEwKPox6jQwZSdqfpl0EI1XFn CSj3irFWGoCutLoPbAYMoHRcIQ902pc/jCq8xK7U51arvwBcJBSKW9ixF36IeaN39xgl ACPbfq+9lpyG1v9cv1y0rwRcHIQkGuQabM8ZyDTPcXHspn4VlFS0A84lS24IIqDTuUUh Er9XD8gCq642CYqmdxPDPYPL84unbvVDafeslE7I00bGEBraMBCmKF4gxKcBOU++DhNw JjlA== X-Gm-Message-State: AODbwcB/AxfoaKbzKPKmPrVtbsHrjEGXS7x42Zcjr62mXQyqMrj2D3Zj J2Mu4H8sQAXGQg== X-Received: by 10.84.224.6 with SMTP id r6mr51698535plj.132.1497214396611; Sun, 11 Jun 2017 13:53:16 -0700 (PDT) Received: from sjc-mahesh-nitro7.cisco.com ([128.107.241.164]) by smtp.gmail.com with ESMTPSA id j22sm720721pfj.56.2017.06.11.13.53.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 11 Jun 2017 13:53:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1B1800A1-55CA-41F6-B20B-BAFAE27B2DA6" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Sun, 11 Jun 2017 13:53:14 -0700 Cc: IPPM Chairs , "ippm@ietf.org" Message-Id: <39D13A18-9287-45B3-984D-1AA4DA9D0F2E@gmail.com> References: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> To: Greg Mirsky X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] [netmod] Important: Guidelines for YANG module authors X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 20:53:20 -0000 --Apple-Mail=_1B1800A1-55CA-41F6-B20B-BAFAE27B2DA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greg, The first place would be read the following two drafts: draft-dsdt-nmda-guidelines = draft-ietf-netmod-revised-datastores = The first one has the guidelines on how existing models need to change. = I would be happy to answer any questions folks might have. > On Jun 11, 2017, at 10:27 AM, Greg Mirsky = wrote: >=20 > Dear All, > wonder how Network Management Datastore Architecture (NMDA) impacts = our data models. Could we get advice, suggestions from NETMOD WG? Invite = someone to our session? Add as one of topics on Sunday? >=20 > Regards, > Greg >=20 > ---------- Forwarded message ---------- > From: Alia Atlas > > Date: Fri, Jun 9, 2017 at 8:05 AM > Subject: Fwd: [netmod] Important: Guidelines for YANG module authors > To: "rtgwg@ietf.org " > >=20 >=20 > At IETF 98 in RTGWG, I mentioned the need for clear guidelines to = handle the changes coming for structuring YANG models. This is the = resulting guidance.=20 >=20 > Regards, > Alia >=20 >=20 > ---------- Forwarded message ---------- > From: Benoit Claise > > Date: Fri, Jun 9, 2017 at 9:56 AM > Subject: [netmod] Important: Guidelines for YANG module authors > To: NETMOD Working Group > >=20 >=20 > Dear all, >=20 > Now that the new NETMOD and NETCONF charters have been approved, it's = time to think about the guidelines for YANG module authors. >=20 > The Network Management Datastore Architecture (NMDA) addresses the = so-called "OpState problem" that has been the subject of much discussion = in the IETF. NMDA is still in development, and there will be a = transition period before NMDA solutions are universally available. >=20 > The NETMOD Datastore Design Team and the Routing Yang Architecture = Design Team have worked with Alia and Benoit to create initial = guidelines for how the NMDA, as defined in = draft-ietf-netmod-revised-datastores = , = impacts Yang models. The draft-dsdt-nmda-guidelines = = individual draft was foundational in helping creating those guidelines. >=20 > If you have questions or concerns on how these guidelines should apply = to work of interest, please contact your WG Chairs or ADs. >=20 > It is our strong recommendation, as ADs with agreement from the NETMOD = WG Chairs, that models SHOULD move as quickly as possible to the NMDA. = The specific approach to be taken for models being developed now and = during the NMDA transition period should be based on both the expected = usage and the maturity of the data model. >=20 > 1. New models and models that are not concerned with the operational = state of configuration information SHOULD immediately be structured to = be NMDA-compatible. >=20 > 2. Models that require immediate support for "in use" and "system = created" information SHOULD be structured for NMDA. Then derived = versions of these models SHOULD be created, either by hand or with = suitable tools, that follow the current modeling strategies. In some = cases, the non-NMDA model may be an existing model and not derived from = the NMDA model. In all cases, the NMDA and non-NMDA modules SHOULD be = published in the same document, with NMDA modules in the document main = body and the non-NMDA modules in an Appendix. The use of the non-NMDA = model will allow temporary bridging of the time period until NMDA = implementations are available. The non-NMDA module names should include = =E2=80=99-state=E2=80=99 appended. >=20 > We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin = Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder, = and all others who helped develop these guidelines. >=20 > Regards, > Alia Atlas, Routing AD > Deborah Brungard, Routing AD > Alvaro Retana, Routing AD > Warren Kumari, Operations & Management AD=20 > Benoit Claise, Operations & Management AD >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = >=20 >=20 >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg = >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_1B1800A1-55CA-41F6-B20B-BAFAE27B2DA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Greg,

The = first place would be read the following two drafts:

draft-dsdt-nmda-guidelines
draft-ietf-netmod-revised-datastores

The first one has the = guidelines on how existing models need to change. I would be happy to = answer any questions folks might have.

On = Jun 11, 2017, at 10:27 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Dear All,
wonder how Network Management Datastore = Architecture (NMDA) impacts our data models. Could we get advice, = suggestions from NETMOD WG? Invite someone to our session? Add as one of = topics on Sunday?

Regards,
Greg

---------- Forwarded = message ----------
From: Alia = Atlas <akatlas@gmail.com>
Date: Fri, Jun = 9, 2017 at 8:05 AM
Subject: Fwd: [netmod] Important: = Guidelines for YANG module authors
To: "rtgwg@ietf.org" <rtgwg@ietf.org>


At IETF 98 in RTGWG, I mentioned the need for clear = guidelines to handle the changes coming for structuring YANG = models.  This is the resulting guidance. 

Regards,
Alia


---------- Forwarded message = ----------
From: Benoit = Claise <bclaise@cisco.com>
Date: Fri, Jun = 9, 2017 at 9:56 AM
Subject: [netmod] Important: Guidelines = for YANG module authors
To: NETMOD Working Group <netmod@ietf.org>


=20 =20 =20
Dear all,

Now that the new NETMOD and NETCONF charters have been approved, it's time to think about the guidelines for YANG module authors.

The Network Management Datastore Architecture (NMDA) addresses the so-called "OpState problem" that has been the subject of much discussion in the IETF. NMDA is still in development, and there will be a transition period before NMDA solutions are universally available.

The NETMOD Datastore Design Team and the Routing Yang Architecture Design Team have worked with Alia and Benoit to create initial guidelines for how the NMDA, as defined in draft-ietf-netmod-revised-datastores, impacts Yang models. The draft-dsdt-nmda-guidelines individual draft was foundational in helping creating those guidelines.

If you have questions or concerns on how these guidelines should apply to work of interest, please contact your WG Chairs or ADs.

It is our strong recommendation, as ADs with agreement from the NETMOD WG Chairs, that models SHOULD move as quickly as possible to the NMDA. The specific approach to be taken for models being developed now and during the NMDA transition period should be based on both the expected usage and the maturity of the data model.

1. New models and models that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA-compatible.

2. Models that require immediate support for "in use" and "system created" information SHOULD be structured for NMDA. Then derived versions of these models SHOULD be created, either by hand or with suitable tools, that follow the current modeling strategies. In some cases, the non-NMDA model may be an existing model and not derived from the NMDA model. In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. The non-NMDA module names should include =E2=80=99-state=E2=80=99 appended.
=
We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder, and all others who helped develop these = guidelines.

Regards,
Alia Atlas, Routing AD
Deborah Brungard, Routing AD
Alvaro Retana, Routing AD
Warren Kumari, Operations & Management AD
Benoit Claise, Operations & Management AD

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



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


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

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_1B1800A1-55CA-41F6-B20B-BAFAE27B2DA6-- From nobody Sun Jun 11 14:08:22 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61652128ACA; Sun, 11 Jun 2017 14:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8vKvk1kEaVw6; Sun, 11 Jun 2017 14:08:18 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23D7128BA2; Sun, 11 Jun 2017 14:08:17 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id s64so3774565oif.1; Sun, 11 Jun 2017 14:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EgpjQWieiYk215ffMMRSWwmF1Nc66moSJSMEgyysqmA=; b=s3DSbPTGOmj3/xTe+FE2KDrKZoUsaccEElvGjKLVKZiCIfCrsegvr9mQnciqcPueT+ 26Y3NoIa1L4ig9n/46pOk980g5YbrZ47sbFxIqoHprczJI/4lyR08X808yfavw+Wy4tv wMLAEXswEaBiJEFiZQJPAM0HaLxwQ3OiqYKTHQzQZD/E+3ObKjH9I1+I4CtY81/fm8MJ I/+9wGKQSRw8CCKS3sDXuPhTy5vzR8zWP9xBxyXmLkHf7lFBFe8UEm7JvFElEsTjuRtp 6wx/IhwT3LX0RjgsrfUY9s/nY9sJ/7MvTfkQykX4lqAcKgb0rfttfmzOSfHh6p5qKE5f fscg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EgpjQWieiYk215ffMMRSWwmF1Nc66moSJSMEgyysqmA=; b=jktPvnzl1Hk+O7NeIswQ4S3gcC2d9YFTrhQRkz0YXL/n0MOkOfROfa9m0MbHQOxNzt n6DZqmGtNmnWm7+kM1r/j8mRmCAh6YGeuVafL/iGjCz8Ahwy+0ApYJwfQEuaWaPQY0XA e3VuLEpzaWmJO3q7Sfl8LUXP/+3/shQRzsfvFv1O40fkbqAQmsaBwqIEj7yVdnK6tQLt TzPqmgS5w7Q7vmZCfw6XI5slw+88jCAaha2zQOx+5JQBU0CS3LWqR4YFdgupbA4/mx5L mVRt6zqSNw3r8BXTUQ8mZ+Y5r137PuyWC4sHD6FbSR19Yjcm7wN3GE5bR1mxCqEn6FlW WjuQ== X-Gm-Message-State: AODbwcDMvgDYXZgJ5kWARKATN+mLDLN4KmfQvMLSXoahD2uZ/eONK4OK sXpuo8K7HQH0uA0lW0dtZqQgWTL4ZQ== X-Received: by 10.202.244.86 with SMTP id s83mr10862858oih.59.1497215297184; Sun, 11 Jun 2017 14:08:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.225 with HTTP; Sun, 11 Jun 2017 14:08:16 -0700 (PDT) Received: by 10.157.52.225 with HTTP; Sun, 11 Jun 2017 14:08:16 -0700 (PDT) In-Reply-To: References: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> <39D13A18-9287-45B3-984D-1AA4DA9D0F2E@gmail.com> From: Greg Mirsky Date: Sun, 11 Jun 2017 14:08:16 -0700 Message-ID: To: Mahesh Jethanandani Cc: ippm@ietf.org, IPPM Chairs Content-Type: multipart/alternative; boundary="001a11c17ca4f0eb3f0551b5991e" Archived-At: Subject: Re: [ippm] [netmod] Important: Guidelines for YANG module authors X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 21:08:20 -0000 --001a11c17ca4f0eb3f0551b5991e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mahesh, I've surely started with these two documents. My first question How we view measurement results? And second, How we view computed metrics,i.e., loss ratio, jitter? Are these operational? Regards, Greg On Jun 11, 2017 1:53 PM, "Mahesh Jethanandani" wrote: Greg, The first place would be read the following two drafts: draft-dsdt-nmda-guidelines draft-ietf-netmod-revised-datastores The first one has the guidelines on how existing models need to change. I would be happy to answer any questions folks might have. On Jun 11, 2017, at 10:27 AM, Greg Mirsky wrote: Dear All, wonder how Network Management Datastore Architecture (NMDA) impacts our data models. Could we get advice, suggestions from NETMOD WG? Invite someone to our session? Add as one of topics on Sunday? Regards, Greg ---------- Forwarded message ---------- From: Alia Atlas Date: Fri, Jun 9, 2017 at 8:05 AM Subject: Fwd: [netmod] Important: Guidelines for YANG module authors To: "rtgwg@ietf.org" At IETF 98 in RTGWG, I mentioned the need for clear guidelines to handle the changes coming for structuring YANG models. This is the resulting guidance. Regards, Alia ---------- Forwarded message ---------- From: Benoit Claise Date: Fri, Jun 9, 2017 at 9:56 AM Subject: [netmod] Important: Guidelines for YANG module authors To: NETMOD Working Group Dear all, Now that the new NETMOD and NETCONF charters have been approved, it's time to think about the guidelines for YANG module authors. The Network Management Datastore Architecture (NMDA) addresses the so-called "OpState problem" that has been the subject of much discussion in the IETF. NMDA is still in development, and there will be a transition period before NMDA solutions are universally available. The NETMOD Datastore Design Team and the Routing Yang Architecture Design Team have worked with Alia and Benoit to create initial guidelines for how the NMDA, as defined in draft-ietf-netmod-revised-datastores , impacts Yang models. The draft-dsdt-nmda-guidelines individual draft was foundational in helping creating those guidelines. If you have questions or concerns on how these guidelines should apply to work of interest, please contact your WG Chairs or ADs. It is our strong recommendation, as ADs with agreement from the NETMOD WG Chairs, that models SHOULD move as quickly as possible to the NMDA. The specific approach to be taken for models being developed now and during the NMDA transition period should be based on both the expected usage and the maturity of the data model. 1. New models and models that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA-compatible. 2. Models that require immediate support for "in use" and "system created" information SHOULD be structured for NMDA. Then derived versions of these models SHOULD be created, either by hand or with suitable tools, that follow the current modeling strategies. In some cases, the non-NMDA model may be an existing model and not derived from the NMDA model. In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. The non-NMDA module names should include =E2=80=99-state=E2=80=99 appended. We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder, and all others who helped develop these guidelines. Regards, Alia Atlas, Routing AD Deborah Brungard, Routing AD Alvaro Retana, Routing AD Warren Kumari, Operations & Management AD Benoit Claise, Operations & Management AD _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm Mahesh Jethanandani mjethanandani@gmail.com --001a11c17ca4f0eb3f0551b5991e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mahesh,
I've surely started with = these two documents. My first question How we view measurement results? And= second, How we view computed metrics,i.e., loss ratio, jitter? Are these o= perational?

Regards, Gre= g=C2=A0

On Jun 11, 2017 1:53 PM, "Mahesh Jethanandani" <mjethanandani@gmail.com> wrote:
Greg,

The first place would be read the following t= wo drafts:


The first one has the guidelines on= how existing models need to change. I would be happy to answer any questio= ns folks might have.

On Jun 11, 2017, at 10:27 AM, Greg Mirsky <gregimirsky@gmail.com<= /a>> wrote:



---------- Forwarded message ----------
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, Jun 9, 2017 at 8:05 AM
Subject: Fwd: [netmod] Important:= Guidelines for YANG module authors
To: "rtgwg@ietf.org" <rtgwg@ietf.org>


At IETF 98 in RTGWG, I mentioned the need for clear guideline= s to handle the changes coming for structuring YANG models.=C2=A0 This is t= he resulting guidance.=C2=A0

Regards,
Al= ia


---------- Forwarded = message ----------
From: Benoit Claise= <bclaise@cisco.com>
Date: Fri, Jun 9, 2017 at 9:56 AMSubject: [netmod] Important: Guidelines for YANG module authors
To: NET= MOD Working Group <= netmod@ietf.org>


=20 =20 =20
Dear all,

Now that the new NETMOD and NETCONF charters have been approved, it's time to think about the guidelines for YANG module authors.
The Network Management Datastore Architecture (NMDA) addresses the so-called "OpState problem" that has been the subject of much discussion in the IETF. NMDA is still in development, and there will be a transition period before NMDA solutions are universally available.

The NETMOD Datastore Design Team and the Routing Yang Architecture Design Team have worked with Alia and Benoit to create initial guidelines for how the NMDA, as defined in = draft-ietf-netmod-revised-datastores, impacts Yang models. The draft-dsdt-nmda-guidelines individual draft was foundational in helping creating those guidelines.

If you have questions or concerns on how these guidelines should apply to work of interest, please contact your WG Chairs or ADs.

It is our strong recommendation, as ADs with agreement from the NETMOD WG Chairs, that models SHOULD move as quickly as possible to the NMDA. The specific approach to be taken for models being developed now and during the NMDA transition period should be based on both the expected usage and the maturity of the data model.

1. New models and models that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA-compatible.

2. Models that require immediate support for "in use" and &qu= ot;system created" information SHOULD be structured for NMDA. Then derived versions of these models SHOULD be created, either by hand or with suitable tools, that follow the current modeling strategies. In some cases, the non-NMDA model may be an existing model and not derived from the NMDA model. In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. The non-NMDA module names should include =E2=80=99-state=E2=80=99 appended.

We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder, and all others who helped develop these guidelines.

Regards,
Alia Atlas, Routing AD
Deborah Brungard, Routing AD
Alvaro Retana, Routing AD
Warren Kumari, Operations & Management AD
Benoit Claise, Operations & Management AD

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


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


_______________________________________________
ippm mailing listippm@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/ippm" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/ippm

Mahesh Jethanandani




--001a11c17ca4f0eb3f0551b5991e-- From nobody Sun Jun 11 15:13:03 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC2A126557; Sun, 11 Jun 2017 15:13:02 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 5AzJ9Jib1yCE; Sun, 11 Jun 2017 15:12:59 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F3F128799; Sun, 11 Jun 2017 15:12:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A99FB65A; Mon, 12 Jun 2017 00:12:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 4uZcbb2-sLj5; Mon, 12 Jun 2017 00:12:55 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 12 Jun 2017 00:12:55 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62CE120091; Mon, 12 Jun 2017 00:12:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Q3Xtw8bmobZF; Mon, 12 Jun 2017 00:12:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 122C620090; Mon, 12 Jun 2017 00:12:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CDA803FBAD59; Mon, 12 Jun 2017 00:12:52 +0200 (CEST) Date: Mon, 12 Jun 2017 00:12:52 +0200 From: Juergen Schoenwaelder To: Greg Mirsky Cc: Mahesh Jethanandani , IPPM Chairs , ippm@ietf.org Message-ID: <20170611221252.GA51301@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Greg Mirsky , Mahesh Jethanandani , IPPM Chairs , ippm@ietf.org References: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> <39D13A18-9287-45B3-984D-1AA4DA9D0F2E@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [ippm] [netmod] Important: Guidelines for YANG module authors X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 22:13:02 -0000 On Sun, Jun 11, 2017 at 02:08:16PM -0700, Greg Mirsky wrote: > Hi Mahesh, > I've surely started with these two documents. My first question How we view > measurement results? And second, How we view computed metrics,i.e., loss > ratio, jitter? Are these operational? I assume you do not configure measurement results, hence these things are all operational state (I assume the corresponding leafs are all config false in YANG lingo). A key benefit of revised datastores is that the new model makes it safe to have config false data (e.g. measurment results) next to the node in the YANG tree where you configure parameters used to obtain measurement results. Before we had revised datastores, it was in some cases not safe to have config false data next to config true data and hence there was a recommendation to have separate config true and config false trees in a YANG module. >From a quick look at draft-ietf-ippm-twamp-yang-03.txt, it seems the ietf-twamp module already has a mixed tree, so there might no change be needed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jun 11 18:03:46 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ADE129B39 for ; Sun, 11 Jun 2017 18:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 SY-tyOpuJNtP for ; Sun, 11 Jun 2017 18:03:42 -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 9C5DF129B3C for ; Sun, 11 Jun 2017 18:03:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOX07144; Mon, 12 Jun 2017 01:03:36 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 12 Jun 2017 02:03:35 +0100 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.16]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Mon, 12 Jun 2017 09:03:30 +0800 From: "dingxiaojian (A)" To: "Brian Trammell (IETF)" , IETF IPPM WG Thread-Topic: [ippm] WGLC on draft-ietf-ippm-alt-mark Thread-Index: AdLjF6bYyiV0+EO+T6OvnpxAxEVPyg== Date: Mon, 12 Jun 2017 01:03:29 +0000 Message-ID: <3B110B81B721B940871EC78F107D848CF68453@DGGEMM506-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.134.227] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.593DE869.00E1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.16, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 16ce55e3afd7fcfc205d8a4008a58fd4 Archived-At: Subject: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 01:03:45 -0000 SGkgQnJpYW4sIFdHLA0KICAgICBJIGhhdmUgcmVhZCB0aHJvdWdoIHRoZSBkcmFmdCBzZXZlcmFs IHRpbWVzLCBhbmQgYmVsaWV2ZSBpdCBwcm92aWRlIGEgZ29vZCBtZWNoYW5pc20gZm9yIHBlcmZv cm1hbmNlIG1lYXN1cmVtZW50LiBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVi bGljYXRpb24uIA0KICAgICBKdXN0IGZldyBjb21tZW50czoNCigxKQlDYW4geW91IHN0YXRlIG1v cmUgY2xlYXIgYWJvdXQgdGhlIHdvcmRzOg0KobBUaHVzIGl0IGlzIG5lY2Vzc2FyeSB0byBjb2xv ciB0aGUgZmxvdyBhcyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUgc291cmNlobENClNvIGRvIHlv dSBoYXZlIGlkZWEgYWJvdXQgaG93IHRvIGNvbG9yIHRoZSBmbG93IG5lYXIgdGhlIHNvdXJjZS4g SXMgdGhlcmUgYW55IG1ldHJpY3MvIGNyaXRlcmlvbnMgdG8gaW1wbGVtZW50Lg0KKDIpCVdlIGtu b3cgdGhlcmUgaGFzIGEgZ2FwIGJldHdlZW4gdGhlIG1lYXN1cmVkIHZhbHVlIGFuZCByZWFsIHZh bHVlIG9mIG1ldHJpY3MgKGUuZy4gZGVsYXksIGppdHRlcikuIEluIHRoZSBkcmFmdCwgdHdvIHRp bWVzdGFtcHMgYXJlIHVzZWQgdG8gY29tcHV0ZSB0aGUgZGVsYXkgb2Ygb25lIHBhY2tldC4gV2Ug YXNzdW1lIGVycm9yMSBpcyB0aGUgbWVhc3VyZW1lbnQgZXJyb3Igb2YgcGFja2V0IDEgKHxtZWFz dXJlZCB2YWx1ZSAtIHJlYWwgdmFsdWUgfCksIGFuZCBlcnJvcjEgbWF5IGJlIHZlcnkgc21hbGwu IEhvd2V2ZXIsIHdoZW4gY29tcHV0aW5nIHRoZSBtZWFuIGRlbGF5LCBtZWFzdXJlbWVudCBlcnJv ciBvZiBtZWFuIGRlbGF5IG1heSBiZSBhdWdtZW50ZWQgYnkgYWNjdW11bGF0aW5nIG1lYXN1cmVt ZW50IGVycm9yIG9mIGEgbG90IG9mIHBhY2tldHMuIFNvLCBpcyB0aGUgcHJvYmxlbSB0YWtlbiBp bnRvIHRoZSBhY2NvdW50IGluIHRoZSBkcmFmdC4NCigzKQlUeXBvczoNClNlYzUuMS4xLCBsYXN0 IHBhcmEsIHNjcmlwdCBjYSBiZS8gc2NyaXB0IGNhbiBiZQ0KU2VjMy4xLjEsIHBhcmEgMSwgZG9j dW1lbnQvZG9jdW1lbnQsIHBhcmE1LCBlcGxhaW5zL2V4cGxhaW5zDQoNCktpbmQgcmVnYXJkcw0K LS0tIFhpYW9qaWFuDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBpcHBtIFttYWlsdG86 aXBwbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEJyaWFuIFRyYW1tZWxsIChJRVRGKQ0Kt6LLzcqx vOQ6IDIwMTfE6jXUwjMwyNUgMjM6NTMNCsrVvP7IyzogSUVURiBJUFBNIFdHIDxpcHBtQGlldGYu b3JnPg0K1vfM4jogW2lwcG1dIFdHTEMgb24gZHJhZnQtaWV0Zi1pcHBtLWFsdC1tYXJrDQoNCkdy ZWV0aW5ncywgSVBQTSwNCg0KQXMgZGlzY3Vzc2VkIGluIENoaWNhZ28sIHRoaXMgbWVzc2FnZSBi ZWdpbnMgYSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWlwcG0tYWx0LW1h cmssIHRvICB0byBydW4gdW50aWwgRU9CIENFU1QgKFVUQyArMikgVHVlc2RheSAyMCBKdW5lIDIw MTcuIFBsZWFzZSByZXBseSB0byBpcHBtQGlldGYub3JnIGluZGljYXRpbmcgd2hldGhlciB5b3Ug YmVsaWV2ZSB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYW5kIGlmIG5v dCwgd2h5IG5vdC4NCg0KTWFueSB0aGFua3MsIGJlc3QgcmVnYXJkcywNCg0KQnJpYW4gKGFzIElQ UE0gY28tY2hhaXIpDQo= From nobody Mon Jun 12 05:55:12 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E210212EAB2 for ; Mon, 12 Jun 2017 05:55:09 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 t_fNW5BiQ0ml for ; Mon, 12 Jun 2017 05:55:07 -0700 (PDT) Received: from mx01.telecomitalia.it (mx01.telecomitalia.it [217.169.121.10]) (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 CADAF12EAAA for ; Mon, 12 Jun 2017 05:55:06 -0700 (PDT) X-AuditID: d9a9790a-943ff7000000118a-d4-593e8f28725d Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx01.telecomitalia.it () with SMTP id 06.6B.04490.82F8E395; Mon, 12 Jun 2017 14:55:04 +0200 (CEST) From: Fioccola Giuseppe To: "Mouli Chandramouli (moulchan)" , IETF IPPM WG , "Brian Trammell (IETF)" Thread-Topic: [ippm] WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2Vzpj3BlOYX4YUisNIH+0MLyVqIX+UWAgAek1gCAAWznsA== Date: Mon, 12 Jun 2017 12:55:03 +0000 Message-ID: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.254] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsXCxfdHSlej3y7SoHOyisXGlndsFj0P3jFb TF0/n8mB2WPK742sHkuW/GTyeLJ/JksAc1QDo01iXl5+SWJJqkJKanGyrZJLZnFyTmJmbmqR QkhqTmpyfq6SQmaKrZKxkkJBTmJyam5qXomtUmJBQWpeipIdlwIGsAEqy8xTSM1Lzk/JzEu3 VfIM9te1sDC11DVUsgssTS0uyVfITS0uTkxPz8xXSE1YL5jR9UK34IVoxaMZl1kaGBeIdjFy ckgImEj0Nf9mBrGFBKYySVyeJAdiswnYSBx8dYKti5GLQ0SghVFi4eJVYEXCAsYSe7ctZAex RQRMJWZ/WcXaxcgBZDtJvJ1jChJmEVCVuH1kKQuIzSsQKNF7bwYLyBwhgSWMEnc+3mMDSXAK 2Er8fXySFcRmFJCVmLB7ESOIzSwgLvFi+gl2iOMEJJbsOc8MYYtKvHz8jxXCNpDYunQfC4St KHFh+VEoW0Zi4ZHJYPcwC2hKrN+lDzFSUWJK90N2iHsEJU7OfMIygVF0FpJtsxA6ZiHpmIWk YwEjyypG0dwKA0O9EkiEZZYk5mQm6mWWbGIEJombKyu5djC+XuV8iFGAg1GJhze83C5SiDWx rLgy9xCjBAezkgjvpx6gEG9KYmVValF+fFFpTmrxIUYfYIBNZJYSTc4HJrC8knhDEwtLQ2ML CyNDCzNTHMJK4ryX/IFmCaQDU1R2ampBahHMOCYOTqkGRmc/K2GWQ3Yy+bPZGW79PKZp3XBu nYLyPKfLW5sDX7gul57X4XNlx5THXCuyluzZcfDFRomZQU68h1f/sWsRv/shZDdXz2dbHvbb TWfjdnHbr1v19QHPPCOp6W5BfUFiVW3it0MuLPGXrlhkYBZh8lZOK3V/asemW4odJtx29074 5F20L550QImlOCPRUIu5qDgRAA+uTzA/AwAA Archived-At: Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 12:55:10 -0000 SGkgTW91bGksIEFsbA0KVGhhbmtzIGZvciB0aGUgc3VwcG9ydC4NCk15IGFuc3dlcnMgaW5s aW5lIHRhZ2dlZCBhcyBbR0ZdLg0KDQpHaXVzZXBwZQ0KDQotLS0tLU1lc3NhZ2dpbyBvcmln aW5hbGUtLS0tLQ0KRGE6IGlwcG0gW21haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddIFBl ciBjb250byBkaSBNb3VsaSBDaGFuZHJhbW91bGkgKG1vdWxjaGFuKQ0KSW52aWF0bzogZG9t ZW5pY2EgMTEgZ2l1Z25vIDIwMTcgMTU6NDcNCkE6IElFVEYgSVBQTSBXRzsgQnJpYW4gVHJh bW1lbGwgKElFVEYpDQpPZ2dldHRvOiBSZTogW2lwcG1dIFdHTEMgb24gZHJhZnQtaWV0Zi1p cHBtLWFsdC1tYXJrDQoNCg0KICAgIEhpICBCcmlhbiwNCiAgICANCiAgICBJIHN1cHBvcnQg V0dMQyBvZiB0aGUgZG9jdW1lbnQgLg0KICAgIA0KICAgIEkgaGF2ZSBzb21lIGNvbW1lbnRz LCBmb3IgY29uc2lkZXJhdGlvbiBhcyBwYXJ0IG9mIHRoaXMgV0dMQy4gDQoNCiAgICBUaGUg bGFuZ3VhZ2UgbmVlZHMgdG8gYmUgdGlnaHRlbmVkIHVwLCBJIHdvdWxkIGhvcGUgdGhlIEdF Ti1BUlQgcmV2aWV3IHdvdWxkIHRha2UgY2FyZSBvZiB0aGF0LiANCg0KICAgICBJcyBjb2xv cmluZyBvciBtYXJraW5nICBvZiBhIHBhY2tldCBjb25zaWRlcmVkIGFjdGl2ZSBvZiBwYXNz aXZlID8gDQoNCltHRl06IEEgc21hbGwgbmV3IHN1YnNlY3Rpb24gYW5kIGEgcmVmZXJlbmNl IHRvIFJGQzc3OTkgd2lsbCBiZSBhZGRlZCB3aXRoaW4gdGhlIEludHJvZHVjdGlvbi4gSW4g YWRkaXRpb24sIGlmIElQUE0gYWdyZWUsIHRoZSBjYXRlZ29yaXphdGlvbiBvZiBtYXJraW5n IG1ldGhvZCB3aWxsIGJlIGRldGFpbGVkOiBpdCBjYW4gYmUgY29uc2lkZXJlZCBoeWJyaWQg b3IgcGFzc2l2ZSBkZXBlbmRpbmcgb24gdGhlIGNhc2UgKGJpdHMgZGVkaWNhdGVkIG9yIG5v dCkuDQoNCiAgIER1cmluZyBhICBibG9jayAxLCAzLCDigKYsIG4rMSAgc2hvdWxkIGJlICAx LCAzLCDigKYsIDJuKzEgICANCg0KICAgZHVyaW5nIGEgQiBibG9jayAoYmxvY2tzIDIsIDQg YW5kIG4pICBzaG91bGQgYmUgICAgMiwgNCwg4oCmLCAybg0KDQpbR0ZdOiBPaywgSXQgd2ls bCBiZSBmaXhlZC4NCg0KVGhhbmtzDQpNb3VsaQ0KICAgIA0KPiBPbiBNYXkgMzAsIDIwMTcs IGF0IDExOjUzIEFNLCBCcmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+ IHdyb3RlOg0KICAgID4gDQogICAgPiBHcmVldGluZ3MsIElQUE0sDQogICAgPiANCiAgICA+ IEFzIGRpc2N1c3NlZCBpbiBDaGljYWdvLCB0aGlzIG1lc3NhZ2UgYmVnaW5zIGEgV29ya2lu ZyBHcm91cCBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1pcHBtLWFsdC1tYXJrLCB0byAgdG8g cnVuIHVudGlsIEVPQiBDRVNUIChVVEMgKzIpIFR1ZXNkYXkgMjAgSnVuZSAyMDE3LiBQbGVh c2UgcmVwbHkgdG8gaXBwbUBpZXRmLm9yZyBpbmRpY2F0aW5nIHdoZXRoZXIgeW91IGJlbGll dmUgdGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24sIGFuZCBpZiBub3Qs IHdoeSBub3QuDQogICAgPiANCiAgICA+IE1hbnkgdGhhbmtzLCBiZXN0IHJlZ2FyZHMsDQog ICAgPiANCiAgICA+IEJyaWFuIChhcyBJUFBNIGNvLWNoYWlyKQ0KICAgID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IGlwcG0gbWFp bGluZyBsaXN0DQogICAgPiBpcHBtQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCiAgICANCiAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIGlwcG0gbWFpbGluZyBsaXN0 DQogICAgaXBwbUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXBwbQ0KICAgIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0KDQpRdWVzdG8gbWVz c2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVu dGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxz aWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3Rl IGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJp YXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNl bWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0 ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gDQoN ClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBt YXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRk cmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVz ZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55 IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBU aGFua3MuIA0KDQpSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1h aWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQo= From nobody Mon Jun 12 06:27:37 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596C51273B1 for ; Mon, 12 Jun 2017 06:27:35 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IfsFfCJKgjxw for ; Mon, 12 Jun 2017 06:27:33 -0700 (PDT) Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (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 E7D3A126D05 for ; Mon, 12 Jun 2017 06:27:32 -0700 (PDT) X-AuditID: d9a97916-5e3ff70000000fe7-0c-593e96c26502 Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id 08.29.04071.2C69E395; Mon, 12 Jun 2017 15:27:30 +0200 (CEST) From: Fioccola Giuseppe To: "dingxiaojian (A)" , "Brian Trammell (IETF)" , IETF IPPM WG Thread-Topic: [ippm] WGLC on draft-ietf-ippm-alt-mark Thread-Index: AdLjF6bYj3BlOYX4YUisNIH+0MLyVgAR9ipw Date: Mon, 12 Jun 2017 13:27:29 +0000 Message-ID: References: <3B110B81B721B940871EC78F107D848CF68453@DGGEMM506-MBS.china.huawei.com> In-Reply-To: <3B110B81B721B940871EC78F107D848CF68453@DGGEMM506-MBS.china.huawei.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.230] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="gb2312" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsXCxfdHSvfQNLtIg+5pEhbvd91lstjY8o7N oufBO2YHZo+WI29ZPZYs+cnk8WT/TJYA5qgGRpvEvLz8ksSSVIWU1OJkWyWXzOLknMTM3NQi hZDUnNTk/FwlhcwUWyVjJYWCnMTk1NzUvBJbpcSCgtS8FCU7LgUMYANUlpmnkJqXnJ+SmZdu q+QZ7K9rYWFqqWuoZBdYmlpckq+Qm1pcnJienpmvkJqwXjBjf9d+9oJ9MhUfFm5mbWB8IN3F yMkhIWAiMa9/IlMXIxeHkMBUJokVvQeZQRJsAjYSB1+dYAOxRQRqJb5+3sYCYgsLGEvs3baQ HSJuKjH7yypWCNtIYva6rWC9LAKqEk8/PwDr5RUIlFj4eC9YXEggWGJb1z2wek6BEIl9d9aB zWEUkJWYsHsRI4jNLCAu8WL6CXaI4wQkluw5zwxhi0q8fPyPFcI2kNi6dB8LhK0osffHAaga GYmFRyazQszRkpjX8JsJwlaUmNL9kB3iHkGJkzOfsExgFJ2FZN0sJC2zkLTMQtKygJFlFaNo boWBkV4JJM4ySxJzMhP1Mks2MQJTxc2VlWI7GFvXOh9iFOBgVOLhPTfZLlKINbGsuDL3EKME B7OSCO/nKUAh3pTEyqrUovz4otKc1OJDjD7AEJvILCWanA9MY3kl8YYmFpaGxhYWRoYWZqY4 hJXEeS/5A80SSAcmquzU1ILUIphxTBycUg2MjYazJv/6lX38YoJOd9qvJr9ltkdOH3APZGvY lXmu0WWxfZXAirl2sxxm/JnoJMZ+RN//8T8W+Ycb2irWmJjs3x3ylsHDj+mN1EX9mZb6D6Rv 1ix75tXSFsul0nCh8tg6Qdcbz+8b8WSe+m/wx98j9HgcY2Zoysu764z3RVXz+2y/fMTu3Rw+ JZbijERDLeai4kQAxPOAZUIDAAA= Archived-At: Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 13:27:35 -0000 WGlhb2ppYW4sDQpUaGFuayB5b3UgZm9yIHRoZSBzdXBwb3J0Lg0KTXkgYW5zd2VycyBpbmxp bmUgdGFnZ2VkIGFzIFtHRl0uDQoNCkdpdXNlcHBlDQoNCi0tLS0tTWVzc2FnZ2lvIG9yaWdp bmFsZS0tLS0tDQpEYTogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gUGVy IGNvbnRvIGRpIGRpbmd4aWFvamlhbiAoQSkNCkludmlhdG86IGx1bmVkqKwgMTIgZ2l1Z25v IDIwMTcgMDM6MDMNCkE6IEJyaWFuIFRyYW1tZWxsIChJRVRGKTsgSUVURiBJUFBNIFdHDQpP Z2dldHRvOiBSZTogW2lwcG1dIFdHTEMgb24gZHJhZnQtaWV0Zi1pcHBtLWFsdC1tYXJrDQoN CkhpIEJyaWFuLCBXRywNCiAgICAgSSBoYXZlIHJlYWQgdGhyb3VnaCB0aGUgZHJhZnQgc2V2 ZXJhbCB0aW1lcywgYW5kIGJlbGlldmUgaXQgcHJvdmlkZSBhIGdvb2QgbWVjaGFuaXNtIGZv ciBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudC4gSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgcmVh ZHkgZm9yIHB1YmxpY2F0aW9uLiANCiAgICAgSnVzdCBmZXcgY29tbWVudHM6CQ0KKDEpCUNh biB5b3Ugc3RhdGUgbW9yZSBjbGVhciBhYm91dCB0aGUgd29yZHM6DQqhsFRodXMgaXQgaXMg bmVjZXNzYXJ5IHRvIGNvbG9yIHRoZSBmbG93IGFzIGNsb3NlIGFzIHBvc3NpYmxlIHRvIHRo ZSBzb3VyY2WhsQ0KU28gZG8geW91IGhhdmUgaWRlYSBhYm91dCBob3cgdG8gY29sb3IgdGhl IGZsb3cgbmVhciB0aGUgc291cmNlLiBJcyB0aGVyZSBhbnkgbWV0cmljcy8gY3JpdGVyaW9u cyB0byBpbXBsZW1lbnQuDQoNCltHRl06IFRoaXMgaXMgbm90IG1hbmRhdG9yeSwgYnV0IGFz IGNsb3NlIGFzIHBvc3NpYmxlIHRvIHRoZSBzb3VyY2UgaXQgaXMgcG9zc2libGUgdG8gaGF2 ZSBmZXdlciBtYXJraW5nIG5vZGVzIHRoYW4gaW4gdGhlIG1pZGRsZSBvZiB0aGUgbmV0d29y ay4gSXQgaXMganVzdCBhIHN1Z2dlc3Rpb24gYmFzZWQgb24gdGhlIG9wZXJhdGlvbmFsIGV4 cGVyaW1lbnQgbWFkZSBpbiBUSSBuZXR3b3JrLiBJbiB0aGlzIHdheSBlbmQtdG8tZW5kIG1l YXN1cmVtZW50cyBhcmUgYWxzbyBlbmFibGVkLiBJIHByb3Bvc2UgdG8gY2hhbmdlICJuZWNl c3NhcnkiIHdpdGggImFkdmFudGFnZW91cyIuDQoNCigyKQlXZSBrbm93IHRoZXJlIGhhcyBh IGdhcCBiZXR3ZWVuIHRoZSBtZWFzdXJlZCB2YWx1ZSBhbmQgcmVhbCB2YWx1ZSBvZiBtZXRy aWNzIChlLmcuIGRlbGF5LCBqaXR0ZXIpLiBJbiB0aGUgZHJhZnQsIHR3byB0aW1lc3RhbXBz IGFyZSB1c2VkIHRvIGNvbXB1dGUgdGhlIGRlbGF5IG9mIG9uZSBwYWNrZXQuIFdlIGFzc3Vt ZSBlcnJvcjEgaXMgdGhlIG1lYXN1cmVtZW50IGVycm9yIG9mIHBhY2tldCAxICh8bWVhc3Vy ZWQgdmFsdWUgLSByZWFsIHZhbHVlIHwpLCBhbmQgZXJyb3IxIG1heSBiZSB2ZXJ5IHNtYWxs LiBIb3dldmVyLCB3aGVuIGNvbXB1dGluZyB0aGUgbWVhbiBkZWxheSwgbWVhc3VyZW1lbnQg ZXJyb3Igb2YgbWVhbiBkZWxheSBtYXkgYmUgYXVnbWVudGVkIGJ5IGFjY3VtdWxhdGluZyBt ZWFzdXJlbWVudCBlcnJvciBvZiBhIGxvdCBvZiBwYWNrZXRzLiBTbywgaXMgdGhlIHByb2Js ZW0gdGFrZW4gaW50byB0aGUgYWNjb3VudCBpbiB0aGUgZHJhZnQuDQoNCltHRl06IFdlIGRv bid0IHRhbGsgYWJvdXQgZXJyb3IgZWZmZWN0cyBpbiBvdXIgZHJhZnQuIEkgc3VnZ2VzdCB0 byBhZGQgYSBjb25zaWRlcmF0aW9uIGluIHRoZSBtZWFuIGRlbGF5IHNlY3Rpb24gYWJvdXQg dGhlIGFjY3VtdWxhdGluZyBlZmZlY3QgZm9yIHRoZSBtZWFuIG9wZXJhdGlvbi4NCg0KKDMp CVR5cG9zOg0KU2VjNS4xLjEsIGxhc3QgcGFyYSwgc2NyaXB0IGNhIGJlLyBzY3JpcHQgY2Fu IGJlIFNlYzMuMS4xLCBwYXJhIDEsIGRvY3VtZW50L2RvY3VtZW50LCBwYXJhNSwgZXBsYWlu cy9leHBsYWlucw0KDQpbR0ZdOiBUaGFua3MsIGl0IHdpbGwgYmUgZml4ZWQuDQoNCktpbmQg cmVnYXJkcw0KLS0tIFhpYW9qaWFuDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBp cHBtIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEJyaWFuIFRyYW1tZWxs IChJRVRGKQ0Kt6LLzcqxvOQ6IDIwMTfE6jXUwjMwyNUgMjM6NTMNCsrVvP7IyzogSUVURiBJ UFBNIFdHIDxpcHBtQGlldGYub3JnPg0K1vfM4jogW2lwcG1dIFdHTEMgb24gZHJhZnQtaWV0 Zi1pcHBtLWFsdC1tYXJrDQoNCkdyZWV0aW5ncywgSVBQTSwNCg0KQXMgZGlzY3Vzc2VkIGlu IENoaWNhZ28sIHRoaXMgbWVzc2FnZSBiZWdpbnMgYSBXb3JraW5nIEdyb3VwIExhc3QgQ2Fs bCBvbiBkcmFmdC1pZXRmLWlwcG0tYWx0LW1hcmssIHRvICB0byBydW4gdW50aWwgRU9CIENF U1QgKFVUQyArMikgVHVlc2RheSAyMCBKdW5lIDIwMTcuIFBsZWFzZSByZXBseSB0byBpcHBt QGlldGYub3JnIGluZGljYXRpbmcgd2hldGhlciB5b3UgYmVsaWV2ZSB0aGlzIGRvY3VtZW50 IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYW5kIGlmIG5vdCwgd2h5IG5vdC4NCg0KTWFu eSB0aGFua3MsIGJlc3QgcmVnYXJkcywNCg0KQnJpYW4gKGFzIElQUE0gY28tY2hhaXIpDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBt YWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXBwbQ0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRp IHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRl LiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZh bnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29y b3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1 bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBp bW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxs YSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWlu YXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5h dXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2Ug dGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuIA0KDQpSaXNwZXR0YSBsJ2Ft YmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIKioIG5lY2Vzc2FyaW8u DQo= From nobody Mon Jun 12 08:26:34 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6822128DF2 for ; Mon, 12 Jun 2017 08:26:32 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WwsxgUUoDdgg for ; Mon, 12 Jun 2017 08:26:31 -0700 (PDT) Received: from mx01.telecomitalia.it (mx01.telecomitalia.it [217.169.121.10]) (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 BE04612785F for ; Mon, 12 Jun 2017 08:26:30 -0700 (PDT) X-AuditID: d9a9790a-929ff7000000118a-52-593eb2a4bbff Received: from TELMBXA06RM001.telecomitalia.local ( [10.14.252.34]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx01.telecomitalia.it () with SMTP id E8.1C.04490.4A2BE395; Mon, 12 Jun 2017 17:26:28 +0200 (CEST) From: Cociglio Mauro To: "Brian Trammell (IETF)" , IETF IPPM WG Thread-Topic: [ippm] WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2VzpP48WVUYw3kCELo1RKr15YKIhbIFQ Date: Mon, 12 Jun 2017 15:26:28 +0000 Message-ID: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> In-Reply-To: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.254] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsXCxfdHSXfJJrtIgwWvDSw2trxjs+h58I7Z gcljyZKfTB5P9s9kCWCKamC0SczLyy9JLElVSEktTrZVcsksTs5JzMxNLVIISc1JTc7PVVLI TLFVMlZSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+uhYWppa6 hkp2gaWpxSX5CrmpxcWJ6emZ+QqpCesFMzpnLGIr6GGtaHn7jamBcTJLFyMnh4SAicTcJ32s ILaQwFQmiQndcSA2m4CZxJktz9hAbBEBH4muJe/ZQWxhAWOJvdsWskPETSVmf1nFCmEbSXzp OgUWZxFQlfh+oRNsPq9AoMS2L6tZIObbSfzqamMCsTkF7CUWPv4PFmcUkJWYsHsRI4jNLCAu 8WL6CXaI2wQkluw5zwxhi0q8fPyPFcI2kNi6dB/U/YoSF5YfhbJlJBYemcwKMUdP4sbUKWwQ trbEsoWvmSHuEZQ4OfMJywRG0VlI1s1C0jILScssJC0LGFlWMYrmVhgY6pVAoiyzJDEnM1Ev s2QTIzAp3FxZybWD8fUq50OMAhyMSjy8/1bZRQqxJpYVV+YeYpTgYFYS4f2zASjEm5JYWZVa lB9fVJqTWnyI0QcYYhOZpUST84EJK68k3tDEwtLQ2MLCyNDCzBSHsJI47yV/oFkC6cA0lZ2a WpBaBDOOiYNTqoFxb9i7x394NF/c3NiwY31Gt9li14OLH3rIsFZ0VHxZ7brFwcUgX7U3Qjby 7drN2VePXoz//E3mMXvP1BvG3F0b/Q0c/nnFiJ7r8jjePrFzjbLtTy71y+W6bSI1/K3a+pJv OIsqtuzZc4yTb0F2oNyvkweNLD7bfH+e6CATNO/oDPW7xtn2uxcosRRnJBpqMRcVJwIAUewa LTcDAAA= Archived-At: Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 15:26:33 -0000 Hi All, I support the publication as coauthor. Regards. Mauro -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Brian Trammell (IETF) Inviato: marted=EC 30 maggio 2017 17:53 A: IETF IPPM WG Oggetto: [ippm] WGLC on draft-ietf-ippm-alt-mark Greetings, IPPM, As discussed in Chicago, this message begins a Working Group Last Call on dr= aft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday 20 June 2= 017. Please reply to ippm@ietf.org indicating whether you believe this docum= ent is ready for publication, and if not, why not. Many thanks, best regards, Brian (as IPPM co-chair) Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. From nobody Mon Jun 12 08:41:26 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57049129411 for ; Mon, 12 Jun 2017 08:41:25 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 ne60_uEru14O for ; Mon, 12 Jun 2017 08:41:22 -0700 (PDT) Received: from cnet.fi.uba.ar (cnet.fi.uba.ar [157.92.58.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE244127333 for ; Mon, 12 Jun 2017 08:41:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cnet.fi.uba.ar (Postfix) with ESMTP id 749DB140082; Mon, 12 Jun 2017 12:24:55 -0300 (ART) X-Virus-Scanned: Debian amavisd-new at cnet.fi.uba.ar Received: from cnet.fi.uba.ar ([127.0.0.1]) by localhost (cnet.fi.uba.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7ZIqrDegXlI; Mon, 12 Jun 2017 12:24:48 -0300 (ART) Received: from [10.2.49.167] (unknown [200.5.121.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by cnet.fi.uba.ar (Postfix) with ESMTPSA id D6619140077; Mon, 12 Jun 2017 12:24:48 -0300 (ART) Date: Mon, 12 Jun 2017 12:41:17 -0300 (ART) From: "J. Ignacio Alvarez-Hamelin" X-X-Sender: ihameli@quasar.local To: IETF IPPM WG , "Brian Trammell (IETF)" In-Reply-To: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> Message-ID: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="0-1537010799-1497282079=:27213" Archived-At: Subject: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 15:41:25 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1537010799-1497282079=:27213 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Dear all, I support this work. I consider that is a clever way to make measurements. My brief comments: 1) We still need some synchronization support which is hard for iter-domain proposes. 2) I still not convinced about the "central role" give to the mean delay. Giving more importance to quantiles is more accurate because of the heavy tails is traffic and its delays. Best, Ignacio _______________________________________________________________ Dr. Ing. José Ignacio Alvarez-Hamelin CONICET and Facultad de Ingeniería, Universidad de Buenos Aires Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina +54 (11) 5285 0716 / 5285 0705 e-mail: ihameli@cnet.fi.uba.ar web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ _______________________________________________________________ On Tue, 30 May 2017, Brian Trammell (IETF) wrote: > Greetings, IPPM, > > As discussed in Chicago, this message begins a Working Group Last Call on draft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to ippm@ietf.org indicating whether you believe this document is ready for publication, and if not, why not. > > Many thanks, best regards, > > Brian (as IPPM co-chair) > --0-1537010799-1497282079=:27213-- From nobody Mon Jun 12 09:28:35 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556121201F2 for ; Mon, 12 Jun 2017 09:28:34 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9O-4aojEpcNE for ; Mon, 12 Jun 2017 09:28:31 -0700 (PDT) Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (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 6488712942F for ; Mon, 12 Jun 2017 09:28:23 -0700 (PDT) X-AuditID: d9a97916-5e3ff70000000fe7-1a-593ec125ced9 Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id C3.8A.04071.521CE395; Mon, 12 Jun 2017 18:28:21 +0200 (CEST) From: Fioccola Giuseppe To: "J. Ignacio Alvarez-Hamelin" , IETF IPPM WG , "Brian Trammell (IETF)" Thread-Topic: [ippm] WGLC on draft-ietf-ippm-alt-mark Thread-Index: AQHS2Vzpj3BlOYX4YUisNIH+0MLyVqIhUGiAgAAtrjA= Date: Mon, 12 Jun 2017 16:28:20 +0000 Message-ID: References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.230] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsXCxfdHSlf1oF2kweMucYuNLe/YLI7vfsRu 0fPgHbMDs8e/L0+YPZYs+cnk8WT/TJYA5qgGRpvEvLz8ksSSVIWU1OJkWyWXzOLknMTM3NQi hZDUnNTk/FwlhcwUWyVjJYWCnMTk1NzUvBJbpcSCgtS8FCU7LgUMYANUlpmnkJqXnJ+SmZdu q+QZ7K9rYWFqqWuoZBdYmlpckq+Qm1pcnJienpmvkJqwXjBjf8tqloIPvBU7V35jaWCcz93F yMkhIWAi0fTnH2MXIxeHkMBUJolFW9exgyTYBGwkDr46wQZiiwi0Mkq8O28OYgsLGEvs3baQ HSJuKjH7yypWCNtK4uXFFjCbRUBVYllPA1gNr0CgxN99vWC2kECxxJSGWUwgNqeAvcSqG9vB 6hkFZCUm7F7ECGIzC4hLvJh+gh3iOAGJJXvOM0PYohIvH/9jhbANJLYu3ccCYStK7P1xAKpG RmLhkcmsEHP0JG5MncIGYWtLLFv4mhniHkGJkzOfsExgFJ2FZN0sJC2zkLTMQtKygJFlFaNo boWBkV4JJM4ySxJzMhP1Mks2MQJTxc2VlWI7GFvXOh9iFOBgVOLh9V9tFynEmlhWXJl7iFGC g1lJhPf/PqAQb0piZVVqUX58UWlOavEhRh9giE1klhJNzgemsbySeEMTC0tDYwsLI0MLM1Mc wkrivJf8gWYJpAMTVXZqakFqEcw4Jg5OqQbG6U887VetdzZ84ZioKB7tUVNWkun4SL7kRcvV zfZ+x0WvNtfNOL3CO/3B3/8XJCq2Kvz8YG06QcltwtKtzzZMOli8qvzVo93bD2o1/NxtffKq 1cFvT7dJr61T9Z14+6rKu/MN7rM/HGKclPOB77Gve1bgqZT33LcYsllkN6S/7C5fM7V5te1S BiWW4oxEQy3mouJEALe/dcVCAwAA Archived-At: Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 16:28:34 -0000 Hi Jos=E9 Ignacio, Thanks for your support and comments, my answers inline tagged as [GF] Giuseppe -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di J. Ignacio Alvarez-Hame= lin Inviato: luned=EC 12 giugno 2017 17:41 A: IETF IPPM WG; Brian Trammell (IETF) Oggetto: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark Dear all, I support this work. I consider that is a clever way to make measurements. My brief comments: 1) We still need some synchronization support which is hard for iter-domain= proposes. 2) I still not convinced about the "central role" give to the mean delay. Giving more importance to quantiles is more accurate because of the heavy ta= ils is traffic and its delays. [GF]: Mean Delay is now just an option (subsection) of the single marking me= thod. I will try to deemphasize a little bit more. Best, Ignacio _______________________________________________________________ Dr. Ing. Jos=E9 Ignacio Alvarez-Hamelin CONICET and Facultad de Ingenier=EDa, Universidad de Buenos Aires Av. Paseo= Col=F3n 850 - C1063ACV - Buenos Aires - Argentina +54 (11) 5285 0716 / 5285 0705 e-mail: ihameli@cnet.fi.uba.ar web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ _______________________________________________________________ On Tue, 30 May 2017, Brian Trammell (IETF) wrote: > Greetings, IPPM, > > As discussed in Chicago, this message begins a Working Group Last Call on= draft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday 20 Jun= e 2017. Please reply to ippm@ietf.org indicating whether you believe this do= cument is ready for publication, and if not, why not. > > Many thanks, best regards, > > Brian (as IPPM co-chair) > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. From nobody Mon Jun 12 17:59:23 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028B9129AD8 for ; Mon, 12 Jun 2017 17:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 u95fuhISZTyl for ; Mon, 12 Jun 2017 17:59:19 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBF5129466 for ; Mon, 12 Jun 2017 17:59:19 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id i31so77437042ota.3 for ; Mon, 12 Jun 2017 17:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=31RR5x4xpaH2GZ179fbziZjUqYHykCjPcrjXo6uDdtg=; b=GWL6MDgyzGMrU87bxtTMDWgehkliYV1J5LFJuThYnQwH/2EJ+L6RMSpKxGq1/+t3Wb IetSGEyGAGOVqRCj2NPP0Y+z6/yo3VKZtWJUgY9nb/fEVre6dv5z6AkxD6eR6sHhS4Sj DaW757UgmJT32OIe3yE9JOkAtoBbPU18nnWAgIijs8BDd0xe40ajhw/263xrKU/WcLBZ cc+V0LEsFr0QhbFJ+3UhlyW/Ew+OSpCHUl4MPgcsAyNElF6W5xdpsr3I47o0pS3TzBZ7 bpTLpdM8lCKwcDVjAjdplgAq1/zDpSp97wMYPl21aYXUwK0lzU2nqoTCzX+E/znvviME 9lxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=31RR5x4xpaH2GZ179fbziZjUqYHykCjPcrjXo6uDdtg=; b=LOhLGmuAkwgaKVYDCdY5ye6VwKUs8xy3XFuif4XslYQ2p7lvxhYo6eKpxXZeDYxIj0 O8+xgosKAZmNh4q4p2+YOwlHsBlVtiVYsH77NoOTWL7zthY66yVRpQifKwu9B4E5YS1K jema1ObKZ6cFlUA3O0wbGzFJBIpfnMqwegIdE3R51os5XtZ1B+/5iWC8yqh82Fsl4UXe N/81XA+VTDJDV967/pol0mWRQVVYjM7WL6d2h+FDFqdM9m9Nuv6unLRRLYT51rrokhsl xkIyFUFMULSmiNoclw8X/s5V3th8ucXC29YcxwX4Wt1+3EovhQrq3TNL/2NNMgizob+q F0gw== X-Gm-Message-State: AKS2vOzIyYxg+x5S+aCJlJps1m/C4hGp9YiHJSSCw4aycjWafknLnjmp Bl6Nr09iP05Aj8Jb7NcpLidLIrJrkB2e X-Received: by 10.157.54.243 with SMTP id s48mr21114623otd.240.1497315558491; Mon, 12 Jun 2017 17:59:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.225 with HTTP; Mon, 12 Jun 2017 17:59:17 -0700 (PDT) In-Reply-To: <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> From: Greg Mirsky Date: Mon, 12 Jun 2017 17:59:17 -0700 Message-ID: To: "Brian Trammell (IETF)" Cc: "ippm@ietf.org" Content-Type: multipart/alternative; boundary="001a113e238afb0c130551ccf16c" Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jun 2017 00:59:22 -0000 --001a113e238afb0c130551ccf16c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Brian, thank you for listing all the questions so clearly. To me answer depends upon where the required update of the IPPM WG charter takes us. In the current version of the draft I see very little of performance measurement support and no new performance metrics or significant benefits when comparing to existing measurement methods to justify change to the charter. Most of the functionality supported by current version of the draft, as it appears, is to serve not performance measurement but network operation (tracing flow, collecting buffer utilization statistics, etc.) One of the use cases, proof of transit, is, in my view, in the same category. Thus, I don't see much of relevance between draft-brockners-inband-oam-data-05 and performance measurement, performance metrics whether in IP network or overlay network that uses IP as transport. What the update of the WG charter could be? To me it it the first priority question with all others following it. Couple comments on the draft: - I suggest updating the boilerplate and section Conventions to reference RFC 8174 and use the following: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119 ] [RFC8174 ] when, and only when, they appear in all capitals, as shown here. Resulting, do not use capitals but only lower case as this is Experimental document. And because this is Experimental document, remove IANA Consideration section. In conclusion, I'd prefer to discuss the change to the WG charter before updating Milestones and considering adoption of the draft-brockners-inband-oam-data-05. As of now, I don't support either as I don't see any relevance of the draft-brockners-inband-oam-data-05 to the WG charter. Regards, Greg On Tue, May 30, 2017 at 1:17 AM, Brian Trammell (IETF) wrote: > Greetings, IPPM, > > At our Chicago meeting, we decided we needed a single, cleaned-up documen= t > containing appropriate scoping and rationale in order to make a decision = as > to whether we'd like to adopt IOAM within IPPM. This revision of > draft-brockners-inband-oam-data is that document. > > This message, therefore, starts a call for adoption on > draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday > 20 June 2017. Please reply to ippm@ietf.org indicating: > > (1) whether you support addition of the following milestone to the IPPM > charter: > > date TBD: Submit an Experimental draft on inband OAM based measurement > methodologies to the IESG > > (2) whether you support the adoption of draft-brockners-inband-oam-data-0= 5 > as the basis document for this milestone > > (3) whether you commit to reviewing the document if adopted > > > We are aware that there is an open question as to whether we can adopt > draft-brockners-inband-oam-data under our current charter; we'd like to > see if there is IPPM WG consensus on adoption before discussing a > recharter, hopefully before Prague, though we can take face-to-face time = in > Prague for this if necessary. Our intention, as chairs, is to make the > minimal necessary change to the charter should there be consensus for > adoption. However, if you have particular opinions as to how this should = be > done, please also address these in your message. > > Many thanks, best regards, > > Brian (as IPPM co-chair) > > > > > On 29 May 2017, at 17:26, Frank Brockners (fbrockne) > wrote: > > > > Dear IPPM WG, > > > > we=E2=80=99ve just posted an updated version of draft-brockners-inband-= oam-data: > https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is > to address the recent comments on the mailing list. The main change is th= e > verbiage around the need to ensure that IOAM data is kept within the IOAM > domain. In addition, several editorial nits have been cleaned up. > > > > We appreciate your thoughts and comments. > > > > Regards, Frank > > > > _______________________________________________ > > 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 > > --001a113e238afb0c130551ccf16c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,
thank you for listing all the questions so c= learly. To me answer depends upon where the required update of the IPPM WG = charter takes us. In the current version of the draft I see very little of = performance measurement support and no new performance metrics or significa= nt benefits when comparing to existing measurement methods to justify chang= e to the charter. Most of the functionality supported by current version of= the draft, as it appears, is to serve not performance measurement but netw= ork operation (tracing flow, collecting buffer utilization statistics, etc.= ) One of the use cases, proof of transit, is, in my view, in the same categ= ory. Thus, I don't see much of relevance between=C2=A0draft-brockners-inband-oam-data-05 and performance measurement= , performance metrics whether in IP network or overlay network that uses IP= as transport. What the update of the WG charter could be? To me it it the = first priority question with all others following it.
Couple comments on the draft:
  • I suggest updating the boilerplat= e and section Conventions to reference RFC 8174 and use the following:
      The key words "MUS=
T", "MUST NOT", "REQUIRED", "SHALL", &qu=
ot;SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMEN=
DED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be =
interpreted as
      described in BCP 14=
 [RFC2119] [RFC8174] when, and only when, =
they
      appear in all capitals, as shown here.

Resulting, do not use capitals but only low= er case as this is Experimental document. And because this is Experimental = document, remove IANA Consideration section.

In conclusion, I'd prefer to discuss the change to the WG charter be= fore updating Milestones and considering adoption of the=C2=A0draft-brockne= rs-inband-oam-data-05. As of now, I don't support either as I don't= see any relevance of the draft-brockners-inband-oam-data-05=C2=A0to the WG= charter.

Regards,
Greg

On Tue, May 30, 2017 a= t 1:17 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
Greetings, IPPM,

At our Chicago meeting, we decided we needed a single, cleaned-up document = containing appropriate scoping and rationale in order to make a decision as= to whether we'd like to adopt IOAM within IPPM. This revision of draft= -brockners-inband-oam-data is that document.

This message, therefore, starts a call for adoption on draft-brockners-inba= nd-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Plea= se reply to ippm@ietf.org indicating:<= br>
(1) whether you support addition of the following milestone to the IPPM cha= rter:

date TBD: Submit an Experimental draft on inband OAM based measurement meth= odologies to the IESG

(2) whether you support the adoption of draft-brockners-inband-oam-dat= a-05 as the basis document for this milestone

(3) whether you commit to reviewing the document if adopted


We are aware that there is an open question as to whether we can adopt draf= t-brockners-inband-oam-data under our current charter; we'd like t= o see if there is IPPM WG consensus on adoption before discussing a rechart= er, hopefully before Prague, though we can take face-to-face time in Prague= for this if necessary. Our intention, as chairs, is to make the minimal ne= cessary change to the charter should there be consensus for adoption. Howev= er, if you have particular opinions as to how this should be done, please a= lso address these in your message.

Many thanks, best regards,

Brian (as IPPM co-chair)



> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <fbrockne@cisco.com> wrote:
>
> Dear IPPM WG,
>
> we=E2=80=99ve just posted an updated version of draft-brockners-inband= -oam-data: https://tools.ietf.org= /html/draft-brockners-inband-oam-data-05 which is to address = the recent comments on the mailing list. The main change is the verbiage ar= ound the need to ensure that IOAM data is kept within the IOAM domain. In a= ddition, several editorial nits have been cleaned up.
>
> We appreciate your thoughts and comments.
>
> Regards, Frank
>
> _______________________________________________
> 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


--001a113e238afb0c130551ccf16c-- From nobody Thu Jun 15 00:34:26 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05C8129AEE for ; Thu, 15 Jun 2017 00:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=spirent1.onmicrosoft.com 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 Nfju1MIYYx14 for ; Thu, 15 Jun 2017 00:34:22 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0090.outbound.protection.outlook.com [104.47.40.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F251129B07 for ; Thu, 15 Jun 2017 00:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spirent1.onmicrosoft.com; s=selector1-spirent-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Wvxie+l2b49+uy3YjogRWDsvXzfwLkWXCFdHE9NwmeY=; b=lIZ9d2yQm4XGI0NTsyK1BUeVFIWv8UU+Ryhd716e4ctt/S/0LjFFq1Vy3AEhtfNICOzjszeFY8pEaSLXRaW87fwTeDH8UCo10ERfIGfaaC+l9/IXskULwdJCQiOjM8wpiZEb1d5JkA+peCQDBlUokNttMrua93dgOODstBo1fQQ= Received: from SN1PR10MB0719.namprd10.prod.outlook.com (10.163.206.145) by SN1PR10MB0719.namprd10.prod.outlook.com (10.163.206.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Thu, 15 Jun 2017 07:34:20 +0000 Received: from SN1PR10MB0719.namprd10.prod.outlook.com ([10.163.206.145]) by SN1PR10MB0719.namprd10.prod.outlook.com ([10.163.206.145]) with mapi id 15.01.1157.017; Thu, 15 Jun 2017 07:34:20 +0000 From: "Singh, Gurpreet" To: "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for draft-brockners-inband-oam-data Thread-Index: AdLlqV3RqaNt/3tnR1mlcOPHh8OL6Q== Date: Thu, 15 Jun 2017 07:34:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=spirent.com; x-originating-ip: [106.38.17.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR10MB0719; 7:cKXIQFzhtlO/1GDBiZxOaGSsqOTFaoiMebW3Jvf8Jmp3e7dPueKanbKIqVJlRGknDUegC543DIK4G+miJrQBTEV9oqVgGSNf5DATbyb40OjGuAX+4AMh4E1yDzNCg0gZU7SMVd6K/5vPuSSRzTz/3DhbhN3y2e4lAs4ROooOKIjf99nDXb+jLkLhN4+2iMHnJLPofaW3xGgyLeaWUZui815bnUNkUPGcrIQX03PN51+xHXfJhEIPrHYKsoY6ZdOlZmA2P+nNyLeP030cnultvV5OZcmxy/awjQ/p9bXIcP+VzOZIxTaEyYcBDUF+DfgZABgy/E6hu7F/ppFtCe+7JA== x-ms-traffictypediagnostic: SN1PR10MB0719: x-ms-office365-filtering-correlation-id: d4e4eb6c-2653-474f-a5dd-08d4b3c0efbf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN1PR10MB0719; x-disclaimer: Yes x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR10MB0719; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR10MB0719; x-forefront-prvs: 0339F89554 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39400400002)(39410400002)(39450400003)(39840400002)(85714005)(53936002)(2501003)(5640700003)(6506006)(6436002)(77096006)(5630700001)(5660300001)(74316002)(8676002)(55016002)(99286003)(3280700002)(2906002)(3846002)(790700001)(6116002)(2351001)(25786009)(230783001)(72206003)(3660700001)(189998001)(66066001)(38730400002)(122556002)(478600001)(102836003)(6916009)(86362001)(54356999)(14454004)(50986999)(110136004)(7736002)(8936002)(1730700003)(7696004)(2900100001)(54896002)(6306002)(33656002)(81166006)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR10MB0719; H:SN1PR10MB0719.namprd10.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR10MB07193DF1AA15B875D7350F3B91C00SN1PR10MB0719namp_" MIME-Version: 1.0 X-OriginatorOrg: spirent.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2017 07:34:20.0857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: eb68cad0-6bd5-483f-a802-0f72f974373f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR10MB0719 Archived-At: Subject: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 07:34:25 -0000 --_000_SN1PR10MB07193DF1AA15B875D7350F3B91C00SN1PR10MB0719namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (1) whether you support addition of the following milestone to the IPPM cha= rter: Yes, I support setting the milestone. Date may be decided through consensus= and feasibility. (2) whether you support the adoption of draft-brockners-inband-oam-data-05 = as the basis document for this milestone Yes, I support (3) whether you commit to reviewing the document if adopted Yes, I will review the document Regards Gurpreet Singh Spirent Communications e-mail confidentiality. ------------------------------------------------------------------------ This e-mail contains confidential and / or privileged information belonging= to Spirent Communications plc, its affiliates and / or subsidiaries. If yo= u are not the intended recipient, you are hereby notified that any disclosu= re, copying, distribution and / or the taking of any action based upon reli= ance on the contents of this transmission is strictly forbidden. If you hav= e received this message in error please notify the sender by return e-mail = and delete it from your system. Spirent Communications plc Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdo= m. Tel No. +44 (0) 1293 767676 Fax No. +44 (0) 1293 767677 Registered in England Number 470893 Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,= United Kingdom. Or if within the US, Spirent Communications, 27349 Agoura Road, Calabasas, CA, 91301, USA. Tel No. 1-818-676- 2300 --_000_SN1PR10MB07193DF1AA15B875D7350F3B91C00SN1PR10MB0719namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(1) whether you support addition of the following= milestone to the IPPM charter:

 

Yes, I support setting the milestone. Date may be= decided through consensus and feasibility.

 

(2) whether you support the adoption of draft-bro= ckners-inband-oam-data-05 as the basis document for this milestone

Yes, I support

 

(3) whether you commit to reviewing the document = if adopted

Yes, I will review the document

 

Regards

Gurpreet Singh

 





Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------ This e-mail contains confidential and / or privileged information belonging= to Spirent Communications plc, its affiliates and / or subsidiaries. If yo= u are not the intended recipient, you are hereby notified that any disclosu= re, copying, distribution and / or the taking of any action based upon reliance on the contents of this tr= ansmission is strictly forbidden. If you have received this message in erro= r please notify the sender by return e-mail and delete it from your system.=

Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdo= m.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,= United Kingdom.

Or if within the US,

Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300
--_000_SN1PR10MB07193DF1AA15B875D7350F3B91C00SN1PR10MB0719namp_-- From rchang@barefootnetworks.com Fri Jun 16 12:05:29 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8051293D6 for ; Fri, 16 Jun 2017 12:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=barefootnetworks.com 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 y0jmaqOeHqxL for ; Fri, 16 Jun 2017 12:05:27 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0683612426E for ; Fri, 16 Jun 2017 12:05:27 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id u19so75559099qta.3 for ; Fri, 16 Jun 2017 12:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=barefootnetworks.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=ibcwzJ9ilyaFfRjUbFfbmshRNVWIohdlS8dVzdITEXE=; b=JKl7mXCpI3aXIFBM+y7A6Yz4RQoMwJ28/0z3Cc39u55JlaZTxjzVaiBFFmVgsW8sII 2n2Et0+QL4YcQr7DG8neWWwkeUzeQlRcIUYWql6dTicHrtVwU70wDa+sII3VXBDhjgB9 S+h5jgV0xqpnp21+AVjWWIAVWyuNkARt62QRcUKbjh3Zkrzu3BlJZnAUaI3jQiBVmSob 1PYvt7LQFl8vmbZDr1wvmtNnGDXMfwQ2PqsQGC6ehk4+r1MkSSucw30YiIuhA0L6yzJU JvJP2xeBL3tESFi+RKS6XLf7kwd4I5lWk8NB7uOW7/G5+J9uUJmPnOWobyc2ml9Oymug SFXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ibcwzJ9ilyaFfRjUbFfbmshRNVWIohdlS8dVzdITEXE=; b=Ths3Imhsdx90mVxQiqOqN/U3hlXjChXcYDwcBdTedQoBYUqRiHnJYe2VoD9pLPLG1Q 8PBpq2KBqUxuCGNURInKXKzhMPExOVjAHiVlHOUy0l5eBcO7EaTAIkYHdMBXnzyCzgjy mHfPsgyDKZgJiLKgXKkIZbh0t6xCMHvzZcZr5lTuEn6PumfhEUoW5kbnfkhmYWHsjKUA MU613k2V994YJTEuhXvA8bXGkRayEuBQYJeNsP8bjrBTsW6m8CM8DYQZKKnm5lVZ5atc QQuacA42th43Ny5sm3SHD7K2Thefbr163iQQz6MEIl8/lg1pi01IF6/j9Z55oIzABBQ0 vPCg== X-Gm-Message-State: AKS2vOzemmzdETMAMf8ezrEny5WfskIQQbfPW7OgofmKU9So/Ft2U6Ho qP9RWhEczJSirwjF1kk+vSmAEI/YS4WjCPidNA== X-Received: by 10.237.45.3 with SMTP id h3mr15379723qtd.57.1497639925887; Fri, 16 Jun 2017 12:05:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.49.132 with HTTP; Fri, 16 Jun 2017 12:05:25 -0700 (PDT) From: Remy Chang Date: Fri, 16 Jun 2017 12:05:25 -0700 Message-ID: To: ippm@ietf.org Content-Type: multipart/alternative; boundary="94eb2c124cb8c8c6a5055218774f" Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jun 2017 19:07:53 -0000 --94eb2c124cb8c8c6a5055218774f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Brian, Thanks for helping on this. I do believe this is a worthy effort and agree to the 3 questions. Regards, Remy > > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell > (IETF) > Sent: Dienstag, 30. Mai 2017 10:18 > To: ippm@ietf.org > Subject: [ippm] Adoption call for draft-brockners-inband-oam-data > > Greetings, IPPM, > > At our Chicago meeting, we decided we needed a single, cleaned-up documen= t > containing appropriate scoping and rationale in order to make a decision = as > to whether we'd like to adopt IOAM within IPPM. This revision of > draft-brockners-inband-oam-data is that document. > > This message, therefore, starts a call for adoption on > draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday > 20 June 2017. Please reply to ippm@ietf.org indicating: > > (1) whether you support addition of the following milestone to the IPPM > charter: > > date TBD: Submit an Experimental draft on inband OAM based measurement > methodologies to the IESG > > (2) whether you support the adoption of draft-brockners-inband-oam-data-0= 5 > as the basis document for this milestone > > (3) whether you commit to reviewing the document if adopted > > > We are aware that there is an open question as to whether we can adopt > draft-brockners-inband-oam-data under our current charter; we'd like to > see if there is IPPM WG consensus on adoption before discussing a > recharter, hopefully before Prague, though we can take face-to-face time = in > Prague for this if necessary. Our intention, as chairs, is to make the > minimal necessary change to the charter should there be consensus for > adoption. However, if you have particular opinions as to how this should = be > done, please also address these in your message. > > Many thanks, best regards, > > Brian (as IPPM co-chair) > > > > > On 29 May 2017, at 17:26, Frank Brockners (fbrockne) > wrote: > > > > Dear IPPM WG, > > > > we=E2=80=99ve just posted an updated version of draft-brockners-inband-= oam-data: > https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is > to address the recent comments on the mailing list. The main change is th= e > verbiage around the need to ensure that IOAM data is kept within the IOAM > domain. In addition, several editorial nits have been cleaned up. > > > > We appreciate your thoughts and comments. > > > > Regards, Frank > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > > --94eb2c124cb8c8c6a5055218774f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,
Thanks for helping on this.=C2=A0 I do belie= ve this is a worthy effort and agree to the 3 questions.

Regards,
Remy



-----Original Message-----
From: ippm [mailto:ippm-bounces@ie= tf.org] On Behalf Of Brian Trammell (IETF)
Sent: Dienstag, 30. Mai 2017 10:18
To: ippm@ietf.org
Subject: [ippm] Adoption call for draft-brockners-inband-oam-data

Greetings, IPPM,

At our Chicago meeting, we decided we needed a single, cleaned-up document = containing appropriate scoping and rationale in order to make a decision as= to whether we'd like to adopt IOAM within IPPM. This revision of draft= -brockners-inband-oam-data is that document.

This message, therefore, starts a call for adoption on draft-brockners-inba= nd-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Plea= se reply to ippm@ietf.org indicating:<= br>
(1) whether you support addition of the following milestone to the IPPM cha= rter:

date TBD: Submit an Experimental draft on inband OAM based measurement meth= odologies to the IESG

(2) whether you support the adoption of draft-brockners-inband-oam-dat= a-05 as the basis document for this milestone

(3) whether you commit to reviewing the document if adopted


We are aware that there is an open question as to whether we can adopt draf= t-brockners-inband-oam-data under our current charter; we'd like t= o see if there is IPPM WG consensus on adoption before discussing a rechart= er, hopefully before Prague, though we can take face-to-face time in Prague= for this if necessary. Our intention, as chairs, is to make the minimal ne= cessary change to the charter should there be consensus for adoption. Howev= er, if you have particular opinions as to how this should be done, please a= lso address these in your message.

Many thanks, best regards,

Brian (as IPPM co-chair)



> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <fbrockne@cisco.com> wrote:
>
> Dear IPPM WG,
>
> we=E2=80=99ve just posted an updated version of draft-brockners-inband= -oam-data: https://tools.ietf.org= /html/draft-brockners-inband-oam-data-05 which is to address = the recent comments on the mailing list. The main change is the verbiage ar= ound the need to ensure that IOAM data is kept within the IOAM domain. In a= ddition, several editorial nits have been cleaned up.
>
> We appreciate your thoughts and comments.
>
> Regards, Frank
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm

--94eb2c124cb8c8c6a5055218774f-- From nobody Fri Jun 16 12:35:21 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D56126CE8 for ; Fri, 16 Jun 2017 12:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=barefootnetworks.com 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 jiUhvRI1oPli for ; Fri, 16 Jun 2017 12:35:18 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750E71300F0 for ; Fri, 16 Jun 2017 12:35:18 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id p189so30173419lfe.2 for ; Fri, 16 Jun 2017 12:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=barefootnetworks.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=tsZQz3jcmzyzCidU96BWdae/80GZCfeUTbwR4by7jzQ=; b=RNu09HPDNVwNEc4dHEByOSyWR6cyXhLB37IhKVM3XOFemFB380ybR7kgQqzlpWTrA5 uVaIhWDvr07Eu5ixtHXt08Y6q/yKU0Ho1Df3/6a+sYL1bwtgeNzyuHMUn1145USG4C6+ VUzA3NZ6U5JAOQ3i2O3FX0DmtqPxkbN/uFs75JPX8ymZCbXIgtHuzGf63AwgEpB7+Avr HDOg+br5xWauBm4wt0ZiwK4wpdRJZUHBL0X78q2hu2tiuO23ACIWlCrk9FHtqvcT5Pqp P3Co1zf227sd7OYngslbSPLQ5ee9uRoGUpfAD78OwUqNnMuhxfVhb/MCevRj1Equg1PD PsuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tsZQz3jcmzyzCidU96BWdae/80GZCfeUTbwR4by7jzQ=; b=JOdTUkjb7a/wBpgJRWhM2d5s2KuiBFn4J27QCbUuTcbbgY6ZespLH0x0jhJYX0SHQS YXFXA5MgOv+Wq9jGCGZ1JRGroqoaAi+l+qKbQ4tSj3dNp94dt8JhyTi4jokhIRU1zLIl OLsGVE893v67akWYyXxdy0QHSzq8jHEqpomSAMgpthbxmdZm41Hs/7u91cKksCrM5mKa 6RWU4xxGH4cmVOs3d8W+zNlXCxr6UX41BWa4KCzaKTsKRnn5kKaE1RKuacIFQikIhV8R Wo1YmodPOlLxLn3OPjg40XMLR7YXhfWEcrqW9bJzylotDLgl9clitH47KzynjblDdcpm 9pcA== X-Gm-Message-State: AKS2vOwyT7vTHOQtOoEFFjUv1MERuztiInblJShNs6EasjkjEhiC2kfW NorbBXKaWCzPMykacK1GzFdJljSdQf8NRUK2zw== X-Received: by 10.25.227.66 with SMTP id c2mr4440588lfk.22.1497641716478; Fri, 16 Jun 2017 12:35:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.195.76 with HTTP; Fri, 16 Jun 2017 12:35:15 -0700 (PDT) From: Mickey Spiegel Date: Fri, 16 Jun 2017 12:35:15 -0700 Message-ID: To: ippm@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1cbcd4830e68055218e206" Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jun 2017 19:35:21 -0000 --94eb2c1cbcd4830e68055218e206 Content-Type: text/plain; charset="UTF-8" > > Greetings, IPPM, > At our Chicago meeting, we decided we needed a single, cleaned-up document > containing appropriate scoping and rationale in order to make a decision as > to whether we'd like to adopt IOAM within IPPM. This revision of > draft-brockners-inband-oam-data is that document. > This message, therefore, starts a call for adoption on > draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 > June 2017. Please reply to ippm@ietf.org indicating: > (1) whether you support addition of the following milestone to the IPPM > charter: > date TBD: Submit an Experimental draft on inband OAM based measurement > methodologies to the IESG > I support adding this milestone to the IPPM charter. > (2) whether you support the adoption of draft-brockners-inband-oam-data-05 > as the basis document for this milestone > I support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone. > (3) whether you commit to reviewing the document if adopted > I commit to reviewing this document, and plan to help with edits to the document and technical details. Mickey Spiegel We are aware that there is an open question as to whether we can adopt > draft-brockners-inband-oam-data under our current charter; we'd like to see > if there is IPPM WG consensus on adoption before discussing a recharter, > hopefully before Prague, though we can take face-to-face time in Prague for > this if necessary. Our intention, as chairs, is to make the minimal > necessary change to the charter should there be consensus for adoption. > However, if you have particular opinions as to how this should be done, > please also address these in your message. > Many thanks, best regards, > Brian (as IPPM co-chair) --94eb2c1cbcd4830e68055218e206 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greet= ings, IPPM,
At our Chicago meeting, we decided we needed a single, cleaned-up document = containing appropriate scoping and rationale in order to make a decision as= to whether we'd like to adopt IOAM within IPPM. This revision of draft= -brockners-inband-oam-data is that document.
This message, therefore, starts a call for adoption on draft-brockners-inba= nd-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please re= ply to ippm@i= etf.org indicating:
(1) whether you support addition of the following milestone to the IPPM cha= rter:
date TBD: Submit an Experimental draft on inband OAM based measurement meth= odologies to the IESG

I support = adding this milestone to the IPPM charter.
=C2=A0
(2) whether you support the adoption of draft-brockners-inband-oam-data-05 = as the basis document for this milestone

I support the adoption of draft-brockners-inband-oam-data-05 as th= e basis document for this milestone.
=C2=A0
(3) whether you commit to reviewing the document if adopted

I commit to reviewing this document, and plan t= o help with edits to the document and technical details.

Mickey Spiegel


= We are aware that there is an open question as to whether we can adopt draf= t-brockners-inband-oam-data under our current charter; we'd like to see= if there is IPPM WG consensus on adoption before discussing a recharter, h= opefully before Prague, though we can take face-to-face time in Prague for = this if necessary. Our intention, as chairs, is to make the minimal necessa= ry change to the charter should there be consensus for adoption. However, i= f you have particular opinions as to how this should be done, please also a= ddress these in your message.
Many thanks, best regards,
Brian (as IPPM co-chair)

--94eb2c1cbcd4830e68055218e206-- From nobody Sun Jun 18 15:17:51 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CB7129471 for ; Sun, 18 Jun 2017 15:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 VWrRpHSNqqNv for ; Sun, 18 Jun 2017 15:17:47 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 CAA2D126E01 for ; Sun, 18 Jun 2017 15:17:47 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5IMEnvV007982; Sun, 18 Jun 2017 18:17:44 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0083689.ppops.net-00191d01. with ESMTP id 2b55es2n7s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Jun 2017 18:17:44 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v5IMHhvs071799; Sun, 18 Jun 2017 17:17:43 -0500 Received: from dalint01.pst.cso.att.com (dalint01.pst.cso.att.com [135.31.133.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v5IMHeRK071789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Jun 2017 17:17:40 -0500 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by dalint01.pst.cso.att.com (RSA Interceptor); Sun, 18 Jun 2017 22:17:24 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v5IMHNMN029073; Sun, 18 Jun 2017 17:17:24 -0500 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v5IMHH68028872; Sun, 18 Jun 2017 17:17:19 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id D94C8E0428; Sun, 18 Jun 2017 18:17:16 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Sun, 18 Jun 2017 18:17:16 -0400 From: "MORTON, ALFRED C (AL)" To: "Brian Trammell (IETF)" , "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for draft-brockners-inband-oam-data Thread-Index: AQHS2R1AqruOCFv9rE2teRljJTp4IqIrRQhA Date: Sun, 18 Jun 2017 22:17:15 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25FDF7E7@njmtexg5.research.att.com> References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> In-Reply-To: <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.159.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-18_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706180403 Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 22:17:50 -0000 SGkgQnJpYW4gYW5kIElQUE1lcnMsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJy aWFuIFRyYW1tZWxsDQo+IChJRVRGKQ0KLi4uDQo+IA0KPiBUaGlzIG1lc3NhZ2UsIHRoZXJlZm9y ZSwgc3RhcnRzIGEgY2FsbCBmb3IgYWRvcHRpb24gb24gZHJhZnQtYnJvY2tuZXJzLQ0KPiBpbmJh bmQtb2FtLWRhdGEsIHRvIHJ1biB1bnRpbCBFT0IgQ0VTVCAoVVRDICsyKSBUdWVzZGF5IDIwIEp1 bmUgMjAxNy4NCj4gUGxlYXNlIHJlcGx5IHRvIGlwcG1AaWV0Zi5vcmcgaW5kaWNhdGluZzoNCj4g DQo+ICgxKSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkZGl0aW9uIG9mIHRoZSBmb2xsb3dpbmcgbWls ZXN0b25lIHRvIHRoZSBJUFBNDQo+IGNoYXJ0ZXI6DQo+IA0KPiBkYXRlIFRCRDogU3VibWl0IGFu IEV4cGVyaW1lbnRhbCBkcmFmdCBvbiBpbmJhbmQgT0FNIGJhc2VkIG1lYXN1cmVtZW50DQo+IG1l dGhvZG9sb2dpZXMgdG8gdGhlIElFU0cNCltBQ01dIA0KR2l2ZW4gdGhhdCBtb3N0IGhhdmUgY29u Y2x1ZGVkIHRoYXQgaW4tc2l0dSBPQU0gaXMgY2F0ZWdvcml6ZWQgYXMgDQpIeWJyaWQgVHlwZSBJ IChhY2NvcmRpbmcgdG8gUkZDIDc3OTkpLCB0aGUgSSB3b3VsZCBzYXkgdGhhdCB0aGlzDQpzdGF0 ZW1lbnQgaW4gdGhlIGNoYXJ0ZXIgaXMgKnByZXR0eSBjbG9zZSo6DQoNCiAgIEFkZGl0aW9uYWwg bWV0aG9kcyB3aWxsIGJlIGRlZmluZWQgZm9yIHRoZSBjb21wb3NpdGlvbiBhbmQgY2FsaWJyYXRp b24gb2YNCiAgIElQUE0tZGVmaW5lZCBtZXRyaWNzLCBhcyB3ZWxsIGFzIGFjdGl2ZSwgcGFzc2l2 ZSBhbmQgaHlicmlkIG1lYXN1cmVtZW50DQogICBtZXRob2RzIGZvciB0aGVzZSBtZXRyaWNzLg0K DQphbmQgSSBhZ3JlZSB3ZSBjYW4gZWl0aGVyIGFkb3B0IHRoZSBkcmFmdCBub3csIG9yIHdpdGgg YSBzbWFsbCB0d2VhayB0bw0KdGhlIGNoYXJ0ZXIgdGV4dC4gVGhlIG1lYXN1cmVtZW50IG1ldGhv ZHMgbW9zdGx5IGNvbmNlcm4gdGhlIGRhdGEgZmllbGRzLA0KYW5kIGRvIG5vdCBkZWZpbmUgY29t cGxldGUgcHJvdG9jb2wgc29sdXRpb25zIHRoYXQgd2lsbCBiZSBzdWJqZWN0ZWQNCnRvIG1vcmUg Y29tcGxldGUgcmV2aWV3Lg0KDQpRdWVzdGlvbjogSW4gdGhlIHByb3Bvc2VkIG1pbGVzdG9uZSB0 ZXh0LCB3YXMgImluYmFuZCIgdXNlZCB0byBoYXZlIA0KZ2VuZXJhbGl0eSBiZWZvcmUgImluLXNp dHUiIGlzIGNvbnNpZGVyZWQgYW5kIGFkb3B0ZWQ/DQpJIHN1Z2dlc3Qgcy9pbmJhbmQvaW4tc2l0 dS8gaWYgdGhlIG1pbGVzdG9uZSBhbmQgdGhlDQpkcmFmdCBhcmUgYWRvcHRlZCB0b2dldGhlciwg dG8gaGF2ZSBjbGVhciBsaW1pdHMuDQoNCj4gDQo+ICgyKSB3aGV0aGVyIHlvdSBzdXBwb3J0IHRo ZSBhZG9wdGlvbiBvZiBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhLQ0KPiAwNSBhcyB0 aGUgYmFzaXMgZG9jdW1lbnQgZm9yIHRoaXMgbWlsZXN0b25lDQpbQUNNXSANClllcywgSSBzdXBw b3J0IHRoaXMgZHJhZnQgaW4gcGFydGljdWxhci4NCg0KPiANCj4gKDMpIHdoZXRoZXIgeW91IGNv bW1pdCB0byByZXZpZXdpbmcgdGhlIGRvY3VtZW50IGlmIGFkb3B0ZWQNCj4gDQpbQUNNXSANClll cywgSSBhdHRhY2ggYSByZXZpZXcgb2YgdGhlIGZpcnN0IHRocmVlIHNlY3Rpb25zLCBiZWxvdy4N Cg0KcmVnYXJkcywNCkFsDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBJbi1zaXR1IE9BTSBE YXRhIEZpZWxkcyAgICAgICAgICAgICAgICBNYXkgMjAxNw0KDQoNCjEuICBJbnRyb2R1Y3Rpb24N Cg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGRhdGEgZmllbGRzIGZvciAiaW4tc2l0dSIgT3Bl cmF0aW9ucywNCiAgIEFkbWluaXN0cmF0aW9uLCBhbmQgTWFpbnRlbmFuY2UgKE9BTSkuICBJbi1z aXR1IE9BTSByZWNvcmRzIE9BTQ0KICAgaW5mb3JtYXRpb24gd2l0aGluIHRoZSBwYWNrZXQgd2hp bGUgdGhlIHBhY2tldCB0cmF2ZXJzZXMgYSBwYXJ0aWN1bGFyDQogICBuZXR3b3JrIGRvbWFpbi4g IFRoZSB0ZXJtICJpbi1zaXR1IiByZWZlcnMgdG8gdGhlIGZhY3QgdGhhdCB0aGUgT0FNDQogICBk YXRhIGlzIGFkZGVkIHRvIHRoZSBkYXRhIHBhY2tldHMgcmF0aGVyIHRoYW4gaXMgYmVpbmcgc2Vu dCB3aXRoaW4NCiAgIHBhY2tldHMgc3BlY2lmaWNhbGx5IGRlZGljYXRlZCB0byBPQU0uICBBIGRp c2N1c3Npb24gb2YgdGhlDQogICBtb3RpdmF0aW9uIGFuZCByZXF1aXJlbWVudHMgZm9yIGluLXNp dHUgT0FNIGNhbiBiZSBmb3VuZCBpbg0KICAgW0ktRC5icm9ja25lcnMtaW5iYW5kLW9hbS1yZXF1 aXJlbWVudHNdLiAgSW4tc2l0dSBPQU0gaXMgdG8NCiAgIGNvbXBsZW1lbnQgbWVjaGFuaXNtcyBz dWNoIGFzIFBpbmcgb3IgVHJhY2Vyb3V0ZSwgb3IgbW9yZSByZWNlbnQNCiAgIGFjdGl2ZSBwcm9i aW5nIG1lY2hhbmlzbXMgYXMgZGVzY3JpYmVkIGluDQpbQUNNXSAgTm90IGNsZWFyIHRvIG1lIHdo eSB3ZSBuZWVkIHR3byBkaWZmZXJlbnQgZGVmaW5pdGlvbnMgb2YgInR5cGUiLg0KUkZDNzc5OSBj b25zaWRlcnMgT0FNIG1lYXN1cmVtZW50cyBpbiBpdHMgY2F0ZWdvcml6YXRpb24uIA0KSXQgd291 bGQgYmUgZ29vZCB0byBpbmNsdWRlIHRoZSBzcGVjaWZpYyBwaHJhc2VzIG9mIHRoZSBkZWZpbml0 aW9ucw0KdGhhdCBwbGFjZSBpbi1zaXR1IE9BTSBpbiB0aGUgSHlicmlkIFR5cGUgMSBDYXRlZ29y eSwgc29tZSBvZiB3aGljaA0Kd2VyZSBleGNoYW5nZWQgaW4gcmVjZW50IGUtbWFpbCBkaXNjdXNz aW9uIG9mIHRoaXMgZHJhZnQuDQoNCiAgIFtJLUQubGFwdWtob3YtZGF0YXBsYW5lLXByb2JlXS4g IEluIHRlcm1zIG9mICJhY3RpdmUiIG9yICJwYXNzaXZlIg0KICAgT0FNLCAiaW4tc2l0dSIgT0FN IGNhbiBiZSBjb25zaWRlcmVkIGEgaHlicmlkIE9BTSB0eXBlLiAgV2hpbGUgbm8NCiAgIGV4dHJh IHBhY2tldHMgYXJlIHNlbnQsIGluLXNpdHUgT0FNIGFkZHMgaW5mb3JtYXRpb24gdG8gdGhlIHBh Y2tldHMNCiAgIHRoZXJlZm9yZSBjYW5ub3QgYmUgY29uc2lkZXJlZCBwYXNzaXZlLiAgSW4gdGVy bXMgb2YgdGhlDQogICBjbGFzc2lmaWNhdGlvbiBnaXZlbiBpbiBbUkZDNzc5OV0gaW4tc2l0dSBP QU0gY291bGQgYmUgcG9ydHJheWVkIGFzDQogICAiaHlicmlkIE9BTSwgdHlwZSAxIi4gDQpbQUNN XSBzL2h5YnJpZCBPQU0sIHR5cGUgMS9IeWJyaWQgVHlwZSAxLw0KSSBzdWdnZXN0IHRvIHJlc2lz dCB0aGUgdXJnZSB0byB1c2UgZG91YmxlLXF1b3RlcyB3aGVuIGluZGljYXRpbmcgdGVybXMNCnRo YXQgaGF2ZSBmb3JtYWwgZGVmaW5pdGlvbnMgZWxzZXdoZXJlLiBUaGUgZGVmaW5pdGlvbnMgYXJl IHByaW1hcmlseSBmb3IgDQphY3RpdmUvcGFzc2l2ZS9oeWJyaWQgKm1ldGhvZHMqIG9mIG1lYXN1 cmVtZW50IChhbmQgZm9yICptZXRyaWNzKiwgYWx0aG91Z2gNCkknbSBub3Qgc3VyZSB3ZSBuZWVk IHRvIGRlZmluZSBtZXRyaWNzIHlldC4pDQogICAiSW4tc2l0dSIgbWVjaGFuaXNtcyBkbyBub3Qg cmVxdWlyZSBleHRyYQ0KICAgcGFja2V0cyB0byBiZSBzZW50IGFuZCBoZW5jZSBkb24ndCBjaGFu Z2UgdGhlIHBhY2tldCB0cmFmZmljIG1peA0KICAgd2l0aGluIHRoZSBuZXR3b3JrLiAgSW4tc2l0 dSBPQU0gbWVjaGFuaXNtcyBjYW4gYmUgbGV2ZXJhZ2VkIHdoZXJlDQogICBtZWNoYW5pc21zIHVz aW5nIGUuZy4gIElDTVAgZG8gbm90IGFwcGx5IG9yIGRvIG5vdCBvZmZlciB0aGUgZGVzaXJlZA0K ICAgcmVzdWx0cywgc3VjaCBhcyBwcm92aW5nIHRoYXQgYSBjZXJ0YWluIHRyYWZmaWMgZmxvdyB0 YWtlcyBhIHByZS0NCiAgIGRlZmluZWQgcGF0aCwgU0xBIHZlcmlmaWNhdGlvbiBmb3IgdGhlIGxp dmUgZGF0YSB0cmFmZmljLCBkZXRhaWxlZA0KICAgc3RhdGlzdGljcyBvbiB0cmFmZmljIGRpc3Ry aWJ1dGlvbiBwYXRocyBpbiBuZXR3b3JrcyB0aGF0IGRpc3RyaWJ1dGUNCiAgIHRyYWZmaWMgYWNy b3NzIG11bHRpcGxlIHBhdGhzLCBvciBzY2VuYXJpb3MgaW4gd2hpY2ggcHJvYmUgdHJhZmZpYyBp cw0KICAgcG90ZW50aWFsbHkgaGFuZGxlZCBkaWZmZXJlbnRseSBmcm9tIHJlZ3VsYXIgZGF0YSB0 cmFmZmljIGJ5IHRoZQ0KICAgbmV0d29yayBkZXZpY2VzLg0KDQoyLiAgQ29udmVudGlvbnMNCg0K W0FDTV0gbm8gY29tbWVudHMgdGhpcyBzZWN0aW9uDQoNCjMuICBTY29wZSwgQXBwbGljYWJpbGl0 eSwgYW5kIEFzc3VtcHRpb25zDQoNCiAgIEluLXNpdHUgT0FNIGRlcGxveW1lbnQgYXNzdW1lcyBh IHNldCBvZiBjb25zdHJhaW50cywgcmVxdWlyZW1lbnRzLA0KICAgYW5kIGd1aWRpbmcgcHJpbmNp cGxlcyB3aGljaCBhcmUgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbi4NCg0KICAgU2NvcGU6IFRo aXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgZGF0YSBmaWVsZHMgYW5kIGFzc29jaWF0ZWQgZGF0YQ0K ICAgdHlwZXMgZm9yIGluLXNpdHUgT0FNLiAgVGhlIGluLXNpdHUgT0FNIGRhdGEgZmllbGQgY2Fu IGJlIHRyYW5zcG9ydGVkDQogICBieSBhIHZhcmlldHkgb2YgdHJhbnNwb3J0IHByb3RvY29scywg aW5jbHVkaW5nIE5TSCwgU2VnbWVudCBSb3V0aW5nLA0KW0FDTV0gcy90cmFuc3BvcnQvbmV0d29y ay8NCj8gSW4gSUVURiwgdHJhbnNwb3J0IHByb3RvY29scyBhcmUgVURQIGFuZCBUQ1AgKGFuZCBR VUlDKQ0KDQogICBHZW5ldmUsIElQdjYsIG9yIElQdjQuICBFbmNhcHN1bGF0aW9uIGRldGFpbHMg Zm9yIHRoZXNlIGRpZmZlcmVudA0KICAgdHJhbnNwb3J0IHByb3RvY29scyBhcmUgb3V0c2lkZSB0 aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCltBQ01dIHMvRW5jYXBzdWxhdGlvbi9TcGVjaWZp Y2F0aW9uLw0KQ2xlYXJseSwgc29tZSBvZiB0aGUgcHJvdG9jb2xzIG1lbnRpb25lZCBhYm92ZSBw ZXJmb3JtIGVuY2Fwc3VsYXRpb24NCm9mIG90aGVyIHByb3RvY29sIGhlYWRlcnMuIFRoaXMgbWVt byBkZXNjcmliZXMgdGhlIGFkZGl0aW9uYWwgZmllbGRzDQp0byBpbnNlcnQgd2hlbiBmb3JtaW5n IGEgbmV3IGhlYWRlciwgb3Igb3B0aW9uYWwgZmllbGRzIHRvIGluc2VydCBpbg0KYW4gKmV4aXN0 aW5nKiBoZWFkZXIgKGUuZy4sIElQdjQgYW5kIElQdjYpLiBJIHRoaW5rIHRoZSBTY29wZSANCnNo b3VsZCBjbGVhcmx5IGluZGljYXRlIHRoYXQgdGhlc2UgdHdvIHBvc3NpYmlsaXRpZXMgYXJlIGlu Y2x1ZGVkLg0KDQogICBEZXBsb3ltZW50IGRvbWFpbiAob3Igc2NvcGUpIG9mIGluLXNpdHUgT0FN IGRlcGxveW1lbnQ6IElPQU0gaXMgYQ0KICAgbmV0d29yayBkb21haW4gZm9jdXNlZCBmZWF0dXJl LCB3aXRoICJuZXR3b3JrIGRvbWFpbiIgYmVpbmcgYSBzZXQgb2YNCiAgIG5ldHdvcmsgZGV2aWNl cyBvciBlbnRpdGllcyB3aXRoaW4gYSBzaW5nbGUgYWRtaW5pc3RyYXRpb24uICBGb3INCiAgIGV4 YW1wbGUsIGEgbmV0d29yayBkb21haW4gY2FuIGluY2x1ZGUgYW4gZW50ZXJwcmlzZSBjYW1wdXMg dXNpbmcNCiAgIHBoeXNpY2FsIGNvbm5lY3Rpb25zIGJldHdlZW4gZGV2aWNlcyBvciBhbiBvdmVy bGF5IG5ldHdvcmsgdXNpbmcNCiAgIHZpcnR1YWwgY29ubmVjdGlvbnMgLyB0dW5uZWxzIGZvciBj b25uZWN0aXZpdHkgYmV0d2VlbiBzYWlkIGRldmljZXMuDQogICBBIG5ldHdvcmsgZG9tYWluIGlz IGRlZmluZWQgYnkgaXRzIHBlcmltZXRlciBvciBlZGdlLiAgRGVzaWduZXJzIG9mDQogICBjYXJy aWVyIHByb3RvY29scyBmb3IgSU9BTSBtdXN0IHNwZWNpZnkgbWVjaGFuaXNtcyB0byBlbnN1cmUg dGhhdCBpbi0NCltBQ01dIHMvbXVzdC9NVVNULyAgDQogICBzaXR1IE9BTSBkYXRhIHN0YXlzIHdp dGhpbiBhbiBJT0FNIGRvbWFpbi4gIEluIGFkZGl0aW9uLCB0aGUgb3BlcmF0b3INCiAgIG9mIHN1 Y2ggYSBkb21haW4gaXMgZXhwZWN0ZWQgdG8gcHV0IHByb3Zpc2lvbnMgaW4gcGxhY2UgdG8gZW5z dXJlDQogICB0aGF0IElPQU0gZGF0YSBkb2VzIG5vdCBsZWFrIGJleW9uZCB0aGUgZWRnZSBvZiBh biBJT0FNIGRvbWFpbiwgZS5nLg0KICAgdXNpbmcgZm9yIGV4YW1wbGUgcGFja2V0IGZpbHRlcmlu ZyBtZXRob2RzLiAgVGhlIG9wZXJhdG9yIHNob3VsZA0KICAgY29uc2lkZXIgcG90ZW50aWFsIG9w ZXJhdGlvbmFsIGltcGFjdCBvZiBJT0FNIHRvIG1lY2hhbmlzbXMgc3VjaCBhcw0KICAgRUNNUCBw cm9jZXNzaW5nIChlLmcuIGxvYWQtYmFsYW5jaW5nIHNjaGVtZXMgYmFzZWQgb24gcGFja2V0IGxl bmd0aA0KICAgY291bGQgYmUgaW1wYWN0ZWQgYnkgdGhlIGluY3JlYXNlZCBwYWNrZXQgc2l6ZSBk dWUgdG8gSU9BTSksIHBhdGggTVRVDQogICAoaS5lLiBlbnN1cmUgdGhhdCB0aGUgTVRVIG9mIGFs bCBsaW5rcyB3aXRoaW4gYSBkb21haW4gaXMNCiAgIHN1ZmZpY2llbnRseSBsYXJnZSB0byBzdXBw b3J0IHRoZSBpbmNyZWFzZWQgcGFja2V0IHNpemUgZHVlIHRvIElPQU0pDQogICBhbmQgSUNNUCBt ZXNzYWdlIGhhbmRsaW5nIChpLmUuIGluIGNhc2Ugb2YgYSBuYXRpdmUgSVB2NiB0cmFuc3BvcnQs DQogICBJT0FNIHN1cHBvcnQgZm9yIElDTVB2NiBFY2hvIFJlcXVlc3QvUmVwbHkgY291bGQgZGVz aXJlZCB3aGljaCB3b3VsZA0KICAgdHJhbnNsYXRlIGludG8gSUNNUHY2IGV4dGVuc2lvbnMgdG8g ZW5hYmxlIElPQU0gZGF0YSBmaWVsZHMgdG8gYmUNCiAgIGNvcGllZCBmcm9tIGFuIEVjaG8gUmVx dWVzdCBtZXNzYWdlIHRvIGFuIEVjaG8gUmVwbHkgbWVzc2FnZSkuDQoNCltBQ01dIENvbW1lbnRz IG9uIHRoZSBjb250cm9sIHBvaW50IGRlZmluaXRpb24gYmVsb3cuLi4NCiAgIEluLXNpdHUgT0FN IGNvbnRyb2wgcG9pbnRzOiBJT0FNIGRhdGEgZmllbGRzIGFyZSBhZGRlZCB0byBvciByZW1vdmVk DQogICBmcm9tIHRoZSBsaXZlIHVzZXIgdHJhZmZpYyBieSB0aGUgZGV2aWNlcyB3aGljaCBmb3Jt IHRoZSBlZGdlIG9mIGENCiAgIGRvbWFpbi4gIERldmljZXMgd2l0aGluIGFuIElPQU0gZG9tYWlu IGNhbiB1cGRhdGUgYW5kL29yIGFkZCBJT0FNDQogICBkYXRhLWZpZWxkcy4gIERvbWFpbiBlZGdl IGRldmljZXMgY2FuIGJlIGhvc3RzIG9yIG5ldHdvcmsgZGV2aWNlcy4NCg0KICAgVHJhZmZpYy1z ZXRzIHRoYXQgaW4tc2l0dSBPQU0gaXMgYXBwbGllZCB0bzogSU9BTSBjYW4gYmUgZGVwbG95ZWQg b24NCiAgIGFsbCBvciBvbmx5IG9uIHN1YnNldHMgb2YgdGhlIGxpdmUgdXNlciB0cmFmZmljLiAg SXQgU0hPVUxEIGJlDQogICBwb3NzaWJsZSB0byBlbmFibGUgaW4tc2l0dSBPQU0gb24gYSBzZWxl Y3RlZCBzZXQgb2YgdHJhZmZpYyAoZS5nLiwNCiAgIHBlciBpbnRlcmZhY2UsIGJhc2VkIG9uIGFu IGFjY2VzcyBjb250cm9sIGxpc3Qgb3IgZmxvdyBzcGVjaWZpY2F0aW9uDQogICBkZWZpbmluZyBh IHNwZWNpZmljIHNldCBvZiB0cmFmZmljLCBldGMuKSAgVGhlIHNlbGVjdGVkIHNldCBvZg0KICAg dHJhZmZpYyBjYW4gYWxzbyBiZSBhbGwgdHJhZmZpYy4NCg0KICAgRW5jYXBzdWxhdGlvbiBpbmRl cGVuZGVuY2U6IERhdGEgZm9ybWF0cyBmb3IgaW4tc2l0dSBPQU0gU0hPVUxEIGJlDQogICBkZWZp bmVkIGluIGEgdHJhbnNwb3J0LWluZGVwZW5kZW50IG1hbm5lci4gIEluLXNpdHUgT0FNIGFwcGxp ZXMgdG8gYQ0KICAgdmFyaWV0eSBvZiBlbmNhcHN1bGF0aW5nIHByb3RvY29scy4gIEEgZGVmaW5p dGlvbiBvZiBob3cgSU9BTSBkYXRhDQogICBmaWVsZHMgYXJlIGNhcnJpZWQgYnkgZGlmZmVyZW50 IHRyYW5zcG9ydCBwcm90b2NvbHMgaXMgb3V0c2lkZSB0aGUNCiAgIHNjb3BlIG9mIHRoaXMgZG9j dW1lbnQuDQoNCiAgIExheWVyaW5nOiBJZiBzZXZlcmFsIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2xz IChlLmcuLCBpbiBjYXNlIG9mDQogICB0dW5uZWxpbmcpIGFyZSBzdGFja2VkIG9uIHRvcCBvZiBl YWNoIG90aGVyLCBpbi1zaXR1IE9BTSBkYXRhLXJlY29yZHMNCiAgIGNvdWxkIGJlIHByZXNlbnQg YXQgZXZlcnkgbGF5ZXIuICBUaGUgYmVoYXZpb3IgZm9sbG93cyB0aGUgc2hpcHMtaW4tDQogICB0 aGUtbmlnaHQgbW9kZWwuDQoNCiAgIENvbWJpbmF0aW9uIHdpdGggYWN0aXZlIE9BTSBtZWNoYW5p c21zOiBJbi1zaXR1IE9BTSBzaG91bGQgYmUgdXNhYmxlDQogICBmb3IgYWN0aXZlIG5ldHdvcmsg cHJvYmluZywgZW5hYmxpbmcgZm9yIGV4YW1wbGUgYSBjdXN0b21pemVkIHZlcnNpb24NCiAgIG9m IHRyYWNlcm91dGUuICBEZWNhcHN1bGF0aW5nIGluLXNpdHUgT0FNIG5vZGVzIG1heSBoYXZlIGFu IGFiaWxpdHkNCiAgIHRvIHNlbmQgdGhlIGluLXNpdHUgT0FNIGluZm9ybWF0aW9uIHJldHJpZXZl ZCBmcm9tIHRoZSBwYWNrZXQgYmFjayB0bw0KICAgdGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBw YWNrZXQgb3IgdG8gdGhlIGVuY2Fwc3VsYXRpbmcgbm9kZS4NCltBQ01dIEknZCBsaWtlIHRvIHNl ZSBhIHNsaWdodGx5IG1vcmUgY29tcGxldGUgbmFtaW5nIHNjaGVtZSBmb3INCnRoZSBub2RlcyBw YXJ0aWNpcGF0aW5nIGluIElPQU0gbWV0aG9kcy4gWW91IGFscmVhZHkgZGVmaW5lIA0KKklPQU0g Y29udHJvbCBwb2ludHMqIGFib3ZlIHdoaWNoIHNlZW0gdG8gYmUgdGhlIG9yaWdpbmF0b3JzIGFu ZCB0ZXJtaW5hdG9ycw0Kb2YgdGhlIGluc2VydGVkIElPQU0gZmllbGRzLiBUaGVzZSBub2RlcyBh cmUgc29tZXRpbWVzIGVuY2Fwc3VsYXRpbmcgYW5kIA0KZGVjYXBzdWxhdGluZyBub2RlcywgYnV0 IG5vdCBhbHdheXMgKEkgdGhpbmssIHNlZSBjb21tZW50IG9uIElQdjQrdjYpLg0KVGhlcmUgYXJl IGFsc28gbm9kZXMgd2hpY2ggcGFydGljaXBhdGUgaW4gdGhlIElPQU0gbWV0aG9kcyBsb2NhdGVk DQppbnRlcm5hbCB0byB0aGUgYWRtaW5pc3RyYXRpdmUvSU9BTSBkb21haW4uIEkgc3VnZ2VzdCB0 aGF0Og0KIkRldmljZXMgd2l0aGluIGFuIElPQU0gZG9tYWluIGNhbiB1cGRhdGUgYW5kL29yIGFk ZCBJT0FNIGRhdGEtZmllbGRzLiINCmNvdWxkIGhhdmUgYSBkaWZmZXJlbnQgbmFtZSB0aGF0IGRp c3Rpbmd1aXNoZXMgdGhlaXIgcm9sZS4NCkZvciBhIGdpdmVuIHBhdGgsIHRoZXNlIGRldmljZXMg YXJlIHNpbXBseSBtZW1iZXJzIG9mIHRoZSBJT0FNIGRvbWFpbg0KYW5kIHBlcmZvcm0gYSBzdWJz ZXQgb2YgdGhlIElPQU0gZnVuY3Rpb25zLiANCkFsdGhvdWdoIHRoZSByb2xlIG9mIHRoZXNlIGRl dmljZXMgY291bGQgY2hhbmdlIHdpdGggYSBkaWZmZXJlbnQgcGF0aCwNCnRoZXJlIGNvdWxkIGFs c28gYmUgZGV2aWNlcyAob3IgZnVuY3Rpb25zKSB0aGF0IGFyZSBhbHdheXMgaW50ZW5kZWQgdG8N CmJlIGludGVybmFsIHRvIHRoZSBJT0FNIGRvbWFpbiwgYW5kIG5lZWQgb25seSBhIHN1YnNldCBv ZiANCklPQU0gY2FwYWJpbGl0aWVzLiANCkknbGwgbGV0IHRoZSBhdXRob3JzIG5hbWUgdGhlc2Ug Im1lbWJlcnMtb25seSIgbm9kZXMsIGJ1dCBJIHRoaW5rDQp0aGlzIHJvbGUgaXMgdXNlZnVsIHRv IGRpc3Rpbmd1aXNoLiBNeSBndWVzcyBpcyB0aGF0IHRoZXJlIHdpbGwgYmUNCmEgbGlua2FnZSBi ZXR3ZWVuIHRoZXNlIHJvbGVzIGFuZCB0aGUgdGhyZWUgbWFpbiB0eXBlcyBvZiBpbi1zaXR1IGRh dGEgDQpkZWZpbmVkIGVsc2V3aGVyZS4NCg0KICAgSW4tc2l0dSBPQU0gaW1wbGVtZW50YXRpb246 IFRoZSBJT0FNIGRhdGEtZmllbGQgZGVmaW5pdGlvbnMgdGFrZSB0aGUNCiAgIHNwZWNpZmljcyBv ZiBkZXZpY2VzIHdpdGggaGFyZHdhcmUgZGF0YS1wbGFuZSBhbmQgc29mdHdhcmUgZGF0YS1wbGFu ZQ0KICAgaW50byBhY2NvdW50Lg0KDQotPS09LT0tPS09LT0tPS09LT0tPS0NCg0K From nobody Tue Jun 20 00:48:42 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B121287A3 for ; Tue, 20 Jun 2017 00:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 iiFJdS11Ls_A for ; Tue, 20 Jun 2017 00:48:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF656127601 for ; Tue, 20 Jun 2017 00:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6020; q=dns/txt; s=iport; t=1497944918; x=1499154518; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YPecLOHqAv1yRtPsJszT7zr72N0pHJudDMV/u2inH3k=; b=BG8j0S7Vna4ULU77U4Zwg1Sg3sMA0U7anEVh63klVi4DTBzqzLSJAkw2 I42Ykwi4WRwp0qrh/YZqWsZdi5V8qNHtd+30iMP6CrDcXoZLbZ65GA6jI KUT+9/WZcFXsY5j6hc+hszS2Sw1Kctga/Fv+IgaIxBE9Ki3BGv+3lb+Ok I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaAACL0khZ/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0Hg2SKGZF+c5UEghEhC4V4AhqCQj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQECAQEBGwYROgsFBwQCAQgRBAEBAQICIwMCAgIlCxQBCAgCBAENBQgMi?= =?us-ascii?q?hAIEK1LgiaLXQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VYgWCCbjSDJYRWgmE?= =?us-ascii?q?FiVuVBAKHMIM9iGmCEYVHij6VCAEfOIEKdBVJhQ0cgWZ2iEKBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,364,1493683200"; d="scan'208";a="249647426" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2017 07:48:37 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v5K7mb2Z027910 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2017 07:48:37 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Jun 2017 02:48:36 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Tue, 20 Jun 2017 02:48:36 -0500 From: "Frank Brockners (fbrockne)" To: "Carlos Pignataro (cpignata)" , "Brian Trammell (IETF)" CC: "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for draft-brockners-inband-oam-data Thread-Index: AQHS2R1C85PyjBoHHk2al2aC2B7oD6IXc6AAgBYMSBA= Date: Tue, 20 Jun 2017 07:48:36 +0000 Message-ID: <2fd411dc44d641d39888501e3cf9e5d3@XCH-RCD-008.cisco.com> References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.242.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 07:48:41 -0000 SGkgQ2FybG9zLA0KDQpvbiB5b3VyIG5vdGU6ICIgSSBrbm93IHRoZSBkcmFmdCBpcyBub3cgbGFi ZWxlZCBhcyBFeHBlcmltZW50YWwsIGJ1dCBmcmFua2x5IHRoaXMgaXMgbm8g4oCccmVzZWFyY2gg cHJvamVjdOKAnSwgYW5kIHRoZXJl4oCZcyBubyBleHBlcmltZW50IHBlci1zZS4gQ29uc2VxdWVu dGx5LCBJ4oCZZCBzdXBwb3J0IHN0YW5kYXJkcyB0cmFjay4iLg0KDQpJTUhPIGl0IGRvZXMgbWFr ZSBzZW5zZSB0byBtb3ZlIHRvIHN0YW5kYXJkcyB0YWNrcywgYmVjYXVzZSB3ZSBhbHJlYWR5IGhh dmUgYSBmZXcgaW1wbGVtZW50YXRpb25zLCBpbmNsdWRpbmcgdGhlIG9wZW4gc291cmNlIGltcGxl bWVudGF0aW9uIGluIEZELmlvLiBBbmQganVzdCByZWNlbnRseSwgQnJvYWRjb20gYW5kIE5ldHJv bm9tZSBwdWJsaXNoZWQgYSB2aWRlbyBmZWF0dXJpbmcgdGhlaXIgSU9BTSBpbXBsZW1lbnRhdGlv bjogaHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1qOUZiRDRhM0Y0RSAgDQoNClJlZ2Fy ZHMsIEZyYW5rIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaXBwbSBbbWFp bHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcmxvcyBQaWduYXRhcm8g KGNwaWduYXRhKQ0KU2VudDogRGllbnN0YWcsIDYuIEp1bmkgMjAxNyAwNDowMw0KVG86IEJyaWFu IFRyYW1tZWxsIChJRVRGKSA8aWV0ZkB0cmFtbWVsbC5jaD4NCkNjOiBpcHBtQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW2lwcG1dIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWJyb2NrbmVycy1pbmJh bmQtb2FtLWRhdGENCg0KSGksIEJyaWFuLA0KDQpUaGFuayB5b3UgZm9yIGRyaXZpbmcgdGhpcyBw b2xsLg0KDQpJIGNsZWFybHkgc3VwcG9ydCB0aGlzIHdvcmsgYW5kIGJlbGlldmUgaXQgd2lsbCBi ZSBJRVRGLWN5Y2xlcyB2ZXJ5IHdlbGwgaW52ZXN0ZWQgdG8gYWR2YW5jZSBhbmQgcHVibGlzaCB0 aGlzIHdvcmsuDQoNClRvIHRoYXQgZW5kLCBhIGNvdXBsZSBvZiBjb21tZW50czoNCg0KKDEpIEkg c3VwcG9ydCB0aGUgYWRkaXRpb24gb2YgYSBtaWxlc3RvbmUgdG8gSVBQTSwgdG8gaGF0IHRoaXMg d29yayBmcm9tLiBUaGF0IG1heSByZXF1aXJlIGEgb25lLWxpbmVyIOKAnHJlY2hhcnRlcuKAnSwg YnV0IGxldOKAmXMgbm90IGJsb2F0IHRoZSBwcm9jZXNzLXdhcmUuDQoNCkhvd2V2ZXIsIGEgY291 cGxlIG9mIGNvbW1lbnRzOg0KDQpMZXTigJlzIGNoYW5nZSDigJxpbmJhbmQgT0FNIGJhc2Vk4oCd IGZvciDigJxpbi1zaXR14oCdIG9yIOKAnGh5YnJpZCBtb2RlbCBzb21ldGhpbmfigJ0sIG9yIGFu eXRoaW5nIHRoYXQgZG9lcyBub3QgY2F1c2VzIHBvdGVudGlhbCBjb25mdXNpb24uDQoNCldlIGNv dWxkIGdlbmVyYWxpemUg4oCcIG1lYXN1cmVtZW50IG1ldGhvZG9sb2dpZXPigJ0gYXMg4oCcIG1l dGhvZG9sb2dpZXMgaW5jbHVkaW5nIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW504oCdLg0KDQpJIGtu b3cgdGhlIGRyYWZ0IGlzIG5vdyBsYWJlbGVkIGFzIEV4cGVyaW1lbnRhbCwgYnV0IGZyYW5rbHkg dGhpcyBpcyBubyDigJxyZXNlYXJjaCBwcm9qZWN04oCdLCBhbmQgdGhlcmXigJlzIG5vIGV4cGVy aW1lbnQgcGVyLXNlLiBDb25zZXF1ZW50bHksIEnigJlkIHN1cHBvcnQgc3RhbmRhcmRzIHRyYWNr Lg0KDQooMikgRGVmaW5pdGVseS4gZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YSBjb250 aW51ZXMgdG8gaW5jb3Jwb3JhdGUgY29tbXVuaXR5IGZlZWRiYWNrIGFuZCByZXZpZXcgYW5kIGlz IGEgc29saWQgc3RhcnRpbmcgcG9pbnQgZm9yIHNhaWQgbWlsZXN0b25lLg0KDQpUaGFua3MsDQoN CuKAlCBDYXJsb3MuDQoNCg0KPiBPbiBNYXkgMzAsIDIwMTcsIGF0IDQ6MTcgQU0sIEJyaWFuIFRy YW1tZWxsIChJRVRGKSA8aWV0ZkB0cmFtbWVsbC5jaD4gd3JvdGU6DQo+IA0KPiBHcmVldGluZ3Ms IElQUE0sDQo+IA0KPiBBdCBvdXIgQ2hpY2FnbyBtZWV0aW5nLCB3ZSBkZWNpZGVkIHdlIG5lZWRl ZCBhIHNpbmdsZSwgY2xlYW5lZC11cCBkb2N1bWVudCBjb250YWluaW5nIGFwcHJvcHJpYXRlIHNj b3BpbmcgYW5kIHJhdGlvbmFsZSBpbiBvcmRlciB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hl dGhlciB3ZSdkIGxpa2UgdG8gYWRvcHQgSU9BTSB3aXRoaW4gSVBQTS4gVGhpcyByZXZpc2lvbiBv ZiBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhIGlzIHRoYXQgZG9jdW1lbnQuDQo+IA0K PiBUaGlzIG1lc3NhZ2UsIHRoZXJlZm9yZSwgc3RhcnRzIGEgY2FsbCBmb3IgYWRvcHRpb24gb24g ZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YSwgdG8gcnVuIHVudGlsIEVPQiBDRVNUIChV VEMgKzIpIFR1ZXNkYXkgMjAgSnVuZSAyMDE3LiBQbGVhc2UgcmVwbHkgdG8gaXBwbUBpZXRmLm9y ZyBpbmRpY2F0aW5nOg0KPiANCj4gKDEpIHdoZXRoZXIgeW91IHN1cHBvcnQgYWRkaXRpb24gb2Yg dGhlIGZvbGxvd2luZyBtaWxlc3RvbmUgdG8gdGhlIElQUE0gY2hhcnRlcjoNCj4gDQo+IGRhdGUg VEJEOiBTdWJtaXQgYW4gRXhwZXJpbWVudGFsIGRyYWZ0IG9uIGluYmFuZCBPQU0gYmFzZWQgbWVh c3VyZW1lbnQgbWV0aG9kb2xvZ2llcyB0byB0aGUgSUVTRw0KPiANCj4gKDIpIHdoZXRoZXIgeW91 IHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEt MDUgYXMgdGhlIGJhc2lzIGRvY3VtZW50IGZvciB0aGlzIG1pbGVzdG9uZQ0KPiANCj4gKDMpIHdo ZXRoZXIgeW91IGNvbW1pdCB0byByZXZpZXdpbmcgdGhlIGRvY3VtZW50IGlmIGFkb3B0ZWQNCj4g DQo+IA0KPiBXZSBhcmUgYXdhcmUgdGhhdCB0aGVyZSBpcyBhbiBvcGVuIHF1ZXN0aW9uIGFzIHRv IHdoZXRoZXIgd2UgY2FuIGFkb3B0IGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEgdW5k ZXIgb3VyIGN1cnJlbnQgY2hhcnRlcjsgd2UnZCBsaWtlIHRvIHNlZSBpZiB0aGVyZSBpcyBJUFBN IFdHIGNvbnNlbnN1cyBvbiBhZG9wdGlvbiBiZWZvcmUgZGlzY3Vzc2luZyBhIHJlY2hhcnRlciwg aG9wZWZ1bGx5IGJlZm9yZSBQcmFndWUsIHRob3VnaCB3ZSBjYW4gdGFrZSBmYWNlLXRvLWZhY2Ug dGltZSBpbiBQcmFndWUgZm9yIHRoaXMgaWYgbmVjZXNzYXJ5LiBPdXIgaW50ZW50aW9uLCBhcyBj aGFpcnMsIGlzIHRvIG1ha2UgdGhlIG1pbmltYWwgbmVjZXNzYXJ5IGNoYW5nZSB0byB0aGUgY2hh cnRlciBzaG91bGQgdGhlcmUgYmUgY29uc2Vuc3VzIGZvciBhZG9wdGlvbi4gSG93ZXZlciwgaWYg eW91IGhhdmUgcGFydGljdWxhciBvcGluaW9ucyBhcyB0byBob3cgdGhpcyBzaG91bGQgYmUgZG9u ZSwgcGxlYXNlIGFsc28gYWRkcmVzcyB0aGVzZSBpbiB5b3VyIG1lc3NhZ2UuDQo+IA0KPiBNYW55 IHRoYW5rcywgYmVzdCByZWdhcmRzLA0KPiANCj4gQnJpYW4gKGFzIElQUE0gY28tY2hhaXIpDQo+ IA0KPiANCj4gDQo+PiBPbiAyOSBNYXkgMjAxNywgYXQgMTc6MjYsIEZyYW5rIEJyb2NrbmVycyAo ZmJyb2NrbmUpIDxmYnJvY2tuZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiBEZWFyIElQUE0g V0csDQo+PiANCj4+IHdl4oCZdmUganVzdCBwb3N0ZWQgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIGRy YWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGE6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhLTA1IHdoaWNoIGlzIHRvIGFkZHJlc3Mg dGhlIHJlY2VudCBjb21tZW50cyBvbiB0aGUgbWFpbGluZyBsaXN0LiBUaGUgbWFpbiBjaGFuZ2Ug aXMgdGhlIHZlcmJpYWdlIGFyb3VuZCB0aGUgbmVlZCB0byBlbnN1cmUgdGhhdCBJT0FNIGRhdGEg aXMga2VwdCB3aXRoaW4gdGhlIElPQU0gZG9tYWluLiBJbiBhZGRpdGlvbiwgc2V2ZXJhbCBlZGl0 b3JpYWwgbml0cyBoYXZlIGJlZW4gY2xlYW5lZCB1cC4NCj4+IA0KPj4gV2UgYXBwcmVjaWF0ZSB5 b3VyIHRob3VnaHRzIGFuZCBjb21tZW50cy4NCj4+IA0KPj4gUmVnYXJkcywgRnJhbmsNCj4+IA0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGlw cG0gbWFpbGluZyBsaXN0DQo+PiBpcHBtQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IGlwcG0gbWFpbGluZyBsaXN0DQo+IGlwcG1AaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppcHBtIG1haWxpbmcg bGlzdA0KaXBwbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHBtDQo= From nobody Tue Jun 20 00:58:58 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248F2127601; Tue, 20 Jun 2017 00:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 K2Ykbjer6-IW; Tue, 20 Jun 2017 00:58:48 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F751292C5; Tue, 20 Jun 2017 00:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8824; q=dns/txt; s=iport; t=1497945528; x=1499155128; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=YjJxHEPL4MIazF7MmkrAbDtcZgkbg8QP1d/hc7a8M4s=; b=LHYw8hrS18KYQqbi15VxqRGgqk7TCB7aYX1Egrhf0dxqo/Mk77H4CVIS IV+jgRb9EOnqMfMs/eZIbTA7BMGMT5geR8SqkFxmfeH3ZfpOj3BfEM8OF fWX3NsjX+DC75w9t9mFU3m5Pk8ZZn1b/d43xXzDjl4Lh31179xW5Zxxas w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAAAd1UhZ/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9pYoENB419kX6QTYUqghEshXgCglw/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAy1cAgEIEQQBASgHMhQJCAEBBAESCBOJLWQQr2yLXQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFhmOBYIMihR+FPQWeXwKHMIwmghGFR4o+lQgBHziBCnQVh1h?= =?us-ascii?q?2iEKBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,364,1493683200"; d="scan'208,217";a="442969614" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2017 07:58:47 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v5K7wlqa011986 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2017 07:58:47 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Jun 2017 02:58:46 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Tue, 20 Jun 2017 02:58:46 -0500 From: "Frank Brockners (fbrockne)" To: Haoyu song , "ippm@ietf.org" , "draft-brockners-inband-oam-data.authors@ietf.org" Thread-Topic: draft on iOAM scalability improvement Thread-Index: AdLTH0fsZe3MoWIbQhuBeTS1CfmKpQWer/5Q Date: Tue, 20 Jun 2017 07:58:46 +0000 Message-ID: <4f130f2b419445a2a678bc8da745c0a4@XCH-RCD-008.cisco.com> References: <78A2745BE9B57D4F9D27F86655EB87F925845299@SJCEML701-CHM.china.huawei.com> In-Reply-To: <78A2745BE9B57D4F9D27F86655EB87F925845299@SJCEML701-CHM.china.huawei.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.242.239] Content-Type: multipart/alternative; boundary="_000_4f130f2b419445a2a678bc8da745c0a4XCHRCD008ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] draft on iOAM scalability improvement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 07:58:57 -0000 --_000_4f130f2b419445a2a678bc8da745c0a4XCHRCD008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Haoyu, thanks for posting this well written draft. While reading the draft, I was = wondering whether you have considered reversing the logic of your draft: Cu= rrently you start with identifying certain perceived "scalability issues" a= nd offering associated solutions, but you only very briefly touch on the us= e-cases that would require those enhancements and don't detail the required= data-fields. Given that the current focus of the work is to define data-fi= elds for IOAM, would it make sense to describe the new use-cases and the re= quired new data-fields first. The WG could then jointly discuss how to best= fit these new data-fields in. Thoughts? Thanks, Frank From: Haoyu song [mailto:haoyu.song@huawei.com] Sent: Montag, 22. Mai 2017 19:23 To: ippm@ietf.org; draft-brockners-inband-oam-data.authors@ietf.org Subject: draft on iOAM scalability improvement Dear all, We have submitted an iOAM related draft as follows. Please kindly provide = comments and also let us know if you have any questions which will help us= continue to improve the draft. Thank you very much! https://datatracker.ietf.org/doc/draft-song-ippm-ioam-scalability/ Abstract: This document describes several scalability issues in current in-situ OAM documents and proposes corresponding solutions. Specifically, we extend in-situ OAM to support more standard tracing data than is currently defined and add new features to avoid limitations on MTU, bandwidth, forwarding path length, and node processing capability. Haoyu --_000_4f130f2b419445a2a678bc8da745c0a4XCHRCD008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Haoyu,

 

thanks for posting this well written draft. While readi= ng the draft, I was wondering whether you have considered reversing the log= ic of your draft: Currently you start with identifying certain perceived “scalability issues” and of= fering associated solutions, but you only very briefly touch on the use-cas= es that would require those enhancements and don’t detail the require= d data-fields. Given that the current focus of the work is to define data-fields for IOAM, would it make sense to describe th= e new use-cases and the required new data-fields first. The WG could then j= ointly discuss how to best fit these new data-fields in.<= /p>

 

Thoughts?

 

Thanks, Frank

 

From: Haoyu song [mailto:haoyu.song@huawei.com]
Sent: Montag, 22. Mai 2017 19:23
To: ippm@ietf.org; draft-brockners-inband-oam-data.authors@ietf.org<= br> Subject: draft on iOAM scalability improvement

 

Dear all,

 

We have submitted an iOAM relat= ed draft as follows.  Please kindly provide  comments and also le= t us know if you have any questions which will help us continue to improve = the draft. Thank you very much!

 

https://datatracker.ietf.or= g/doc/draft-song-ippm-ioam-scalability/

 

Abstract:<= /p>

   This document d= escribes several scalability issues in current in-situ

   OAM documents a= nd proposes corresponding solutions.  Specifically, we

   extend in-situ = OAM to support more standard tracing data than is

   currently defin= ed and add new features to avoid limitations on MTU,

   bandwidth, forw= arding path length, and node processing capability.

 

 

Haoyu

     &= nbsp;           &nbs= p;       

--_000_4f130f2b419445a2a678bc8da745c0a4XCHRCD008ciscocom_-- From nobody Tue Jun 20 08:55:29 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F128131A7A for ; Tue, 20 Jun 2017 08:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 HNuVKc9fjHuJ for ; Tue, 20 Jun 2017 08:55:26 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8054C131975 for ; Tue, 20 Jun 2017 08:52:11 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4F0D2341050 for ; Tue, 20 Jun 2017 17:52:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.21045); Tue, 20 Jun 2017 17:52:10 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Tue, 20 Jun 2017 17:52:09 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 21329906 for ippm@ietf.org; Tue, 20 Jun 2017 17:52:09 +0200 From: "Brian Trammell (IETF)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_D392697D-0358-47D3-8857-2C5B4F07E71D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 20 Jun 2017 17:52:08 +0200 References: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> To: IETF IPPM WG Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [ippm] Fwd: WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 15:55:28 -0000 --Apple-Mail=_D392697D-0358-47D3-8857-2C5B4F07E71D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This WGLC is concluded. The authors will submit a new version, = addressing WGLC comments, and this version will be submitted to the IESG = for publication. Many thanks to the authors, and to the reviewers for their feedback, Cheers, Brian (as IPPM co-chair) > Begin forwarded message: >=20 > From: "Brian Trammell (IETF)" > Subject: WGLC on draft-ietf-ippm-alt-mark > Date: 30 May 2017 at 17:53:26 GMT+2 > To: IETF IPPM WG >=20 > Greetings, IPPM, >=20 > As discussed in Chicago, this message begins a Working Group Last Call = on draft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday = 20 June 2017. Please reply to ippm@ietf.org indicating whether you = believe this document is ready for publication, and if not, why not. >=20 > Many thanks, best regards, >=20 > Brian (as IPPM co-chair) --Apple-Mail=_D392697D-0358-47D3-8857-2C5B4F07E71D 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 iQIcBAEBCgAGBQJZSUSpAAoJEIoSt78L6kajF4YP/Rxlz+jcPyR5avUzBq3qz8xe utD1e/MmEffN9UNb0S3oON5WgxT2/29on+DvlINnzx1adQsGWRkQ7scpy+ABhbBP b12jxEJUPyYYMmm+eQAtSKoPmVS0a1PdP7q+Z9O2Akbjd9Z0XDkBTtJZPcEid8tg CBObHehQO0EeHz+KWyCE9d+ZdexKsA/gYo6N3n27s2+wjX4jIM2/6KultId/khZ5 n2JxKFiGNpvk0x9rFy6ZABaLagcacJV7fjGLXrAmWSdvfFLvAOlVBJMRbs4uuk5q fNnJHH+T0w5PP+2Ur5bStlLJSYyrbsKp7syjD4p0pfGP4YKOACfjcgqlnWmJceNn yjjydbYZGTKM3JKSQn8Gc8T3TPpTScPKb2wVKPbGpYWKwQCbtwqiwp+xCZRtpmm4 na3sVnA4Tq+Nz0gr/OejMNiBsCGmf+2K+qA7YhYPA75H2fL1lEG+Ta9cZddlXGJ0 Ng2kdrMa6gXZ7pX2DQ44hPybHaw7wtsTVrEdYW1N29EB57X0FttUVqtCmp+xpLEY NmFKqwinxx/v8KcNQdFsEufTDrMBGa0UJfMU2TnSzTProorQPgi72/4MQQo1O5pL XFEI1bCKXtv5cl7ojX4wZL8qOXgS01lBT5ixaUlIl08c7t0XUYca9CRLsV+6s+fZ ZQro4r2N44Wdq78JBZld =XNZn -----END PGP SIGNATURE----- --Apple-Mail=_D392697D-0358-47D3-8857-2C5B4F07E71D-- From nobody Tue Jun 20 09:00:10 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16098131AB2 for ; Tue, 20 Jun 2017 09:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 wASuoTHVq2Ou for ; Tue, 20 Jun 2017 09:00:01 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63C4131AAE for ; Tue, 20 Jun 2017 08:58:54 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B777A34104B for ; Tue, 20 Jun 2017 17:58:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.22733); Tue, 20 Jun 2017 17:58:53 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Tue, 20 Jun 2017 17:58:53 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 21331070 for ippm@ietf.org; Tue, 20 Jun 2017 17:58:53 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_0ACAFAFB-4BAF-4DF2-9E1D-FD9A64F847D8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> Date: Tue, 20 Jun 2017 17:58:53 +0200 Message-Id: <349AC58B-A295-4F48-AC54-F13AF71DD839@trammell.ch> References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> To: "ippm@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jun 2017 16:00:07 -0000 --Apple-Mail=_0ACAFAFB-4BAF-4DF2-9E1D-FD9A64F847D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, all, This call for adoption is concluded. It appears from the discussion that there is broad but not unanimous = support for adoption of this document, but some concerns about how = exactly the charter would need to be modified to bring this work into = IPPM. In any case, there appears to be more than enough support to = investigate a rechartering. The chairs will work with the authors and = the working group to suggest a charter revision for discussion at our = face-to-face meeting in Prague. Cheers, Brian > On 30 May 2017, at 10:17, Brian Trammell (IETF) = wrote: >=20 > Greetings, IPPM, >=20 > At our Chicago meeting, we decided we needed a single, cleaned-up = document containing appropriate scoping and rationale in order to make a = decision as to whether we'd like to adopt IOAM within IPPM. This = revision of draft-brockners-inband-oam-data is that document. >=20 > This message, therefore, starts a call for adoption on = draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday = 20 June 2017. Please reply to ippm@ietf.org indicating: >=20 > (1) whether you support addition of the following milestone to the = IPPM charter: >=20 > date TBD: Submit an Experimental draft on inband OAM based measurement = methodologies to the IESG >=20 > (2) whether you support the adoption of = draft-brockners-inband-oam-data-05 as the basis document for this = milestone >=20 > (3) whether you commit to reviewing the document if adopted >=20 >=20 > We are aware that there is an open question as to whether we can adopt = draft-brockners-inband-oam-data under our current charter; we'd like to = see if there is IPPM WG consensus on adoption before discussing a = recharter, hopefully before Prague, though we can take face-to-face time = in Prague for this if necessary. Our intention, as chairs, is to make = the minimal necessary change to the charter should there be consensus = for adoption. However, if you have particular opinions as to how this = should be done, please also address these in your message. >=20 > Many thanks, best regards, >=20 > Brian (as IPPM co-chair) >=20 >=20 >=20 >> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) = wrote: >>=20 >> Dear IPPM WG, >>=20 >> we=E2=80=99ve just posted an updated version of = draft-brockners-inband-oam-data: = https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is = to address the recent comments on the mailing list. The main change is = the verbiage around the need to ensure that IOAM data is kept within the = IOAM domain. In addition, several editorial nits have been cleaned up. >>=20 >> We appreciate your thoughts and comments. >>=20 >> Regards, Frank >>=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=_0ACAFAFB-4BAF-4DF2-9E1D-FD9A64F847D8 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 iQIcBAEBCgAGBQJZSUY9AAoJEIoSt78L6kajNkoP/jb5UfrYCkCjTfLcFEei6k9u pgG5jf72GVQBtuIFpFqu5/TGXB5v4ZTNs5LuyyHZ5GLmQI0Vo0489eHls/dGdrvc aKgF3xrU4DmSfX7rCTxJM/7SO3RyWAcn+k6rgco8Z+06IJgb7JEvbksUNdxwLGzg wKWQW0zSfZlUrIK9HQYagECMqsPKtNElR0lnrwXMyhE1HGYE4Z/86hMq6bURdTgm 3kvAkRFUmKhWzHiY1UvjoASM+NpO3smzr/UdlTcxC6JIiJLgzObK0FaFCZTpqoug cvkvKjQItJ2JnBHrh7mDMd9FKuXFa2NR3wvAjv3uynfwphr2dUDPCA4O97N7+Z+A FzWmFU4XNI6yMq9dC1GoFdapjFTCkj6WgX88T8B44Q/YIrXQ1S4ki2K5mzqyjqWy U/na1hRBFo19zUbl7wPFOpyjcHCVq6PISJ+2K3sC0mG4k4UmRtuN9PNtcwSGHQXs W7BIzfb8PBGIFNoJ/6SzX5YbLCF97mQQBnapC/Fo3rEYpnrrM1qbyzOn2hNKooHn MGzhSmN/cGgfhYdDLRNy+SHU733FNmAiz3yeftd3Xlutvf+I/yP2HP/ls59vqUBB 8bNhXBAtmq7v69ISBOQFc4yGUefQRMN9VyUwpq3NQHXyd0wSUB21HUAamqrD2r+m 5zGo2I6p8fR1ROHMPGFc =uXwV -----END PGP SIGNATURE----- --Apple-Mail=_0ACAFAFB-4BAF-4DF2-9E1D-FD9A64F847D8-- From nobody Tue Jun 20 18:49:02 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A65C129A8F for ; Tue, 20 Jun 2017 18:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com 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 kemyVrpOGHCb for ; Tue, 20 Jun 2017 18:49:00 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B281296C9 for ; Tue, 20 Jun 2017 18:48:59 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id c11so58743786wrc.3 for ; Tue, 20 Jun 2017 18:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=Jv609vJbm64iVooBxYkPnuBpfvu2eI6dI03w7kqYPOI=; b=WGWYtI4Lr/g7frMzqHHphyxcBLzcFPvaiIaXOW5EcqYg36qWoajqPYS0vN1yD1TmAU 8z9zxde479HjFgmSiIxu+TcNgTFlmqMjwpcCR6K3V9dMjBX7fsCFSgzaW1A77ZCo/EcL bC9ifiqNcRIY9ZIyFfU4Vx74k+1PIg3MGf05Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=Jv609vJbm64iVooBxYkPnuBpfvu2eI6dI03w7kqYPOI=; b=P2BxvxjSVUPdWt/Cp6o7K1iwpXPz64tTqcUn0LBvKUnrcqPFT1c0FlEIeWnxnM64da 1jbl+YCGlTzYTo2plyocdkbJvjjfsu27Fne6wRM09t5JmR4Dq0AA9L1G84N4Iq81Jar2 UBZNWEEtbeiyLubu6+C61I+IMPkYoE8Ytph5+NpQDIFpYa1T3TentR9EuMO508zSKkP2 LfGOemUxsEQOU3polayUHz806pRH5qKBV+PVyKlkaJnh5iwf0kZ62aOBFQ9/fyfJOaID T0moa37dNHum3WQb2SARW+PNDs0Gt1F2KlUuLf7uyIjCdyazsYp78AgfVbg4UVtMF/i5 +LnA== X-Gm-Message-State: AKS2vOy6QxwIB21ci0wOrIJH7pNjxwcXBvCC8jo65A/0VS7yxq0m6qbJ uQc1agTaJlIc2Bt4XSnA5w== X-Received: by 10.28.71.147 with SMTP id m19mr4597218wmi.92.1498009737886; Tue, 20 Jun 2017 18:48:57 -0700 (PDT) Received: from c02rq0djfvh9.dhcp.broadcom.net ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id h16sm29996085wma.14.2017.06.20.18.48.56 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Jun 2017 18:48:57 -0700 (PDT) From: Shahram Davari Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 20 Jun 2017 18:48:54 -0700 To: ippm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [ippm] Delta Times in draft-ietf-ippm-6man-pdm-option-12 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jun 2017 01:49:01 -0000 Hi, I am trying to understand the rational and the procedure that the = DELTATLS is calculated. Usually there are many packets in fly between Host A to Host B. However = the DELATTLS requires=20 a packet to be sent from A to B and then reply come back from B to A = before the next packet is sent. This doesn=E2=80=99t seem realistic. I am assuming the only way to = correlate the Transmit and receive packet is=20 by 5-tupple. So there is no packet handle to correlate the transmit and = receive packet, which means A has to wait for reply to come back before sending next packet. Is this the intention? are the PDM packets synthetic packets or they are = added as option header to data packets (piggyback)? if they are not synthetic packets then the existing mechanism doesn=E2=80=99= t work. Sorry that I have not been part of this discussion, so I may not know = the reasons for DELATTLS. I am wondering why simply the transmit timestamp is not sent in the packet so that A does not need to = maintain state per packet. Thanks Shahram= From nobody Thu Jun 22 08:09:38 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA69129ADE; Thu, 22 Jun 2017 08:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mellanox.com 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 5z0spHUGnAOF; Thu, 22 Jun 2017 08:09:34 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0068.outbound.protection.outlook.com [104.47.1.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AF5126DC2; Thu, 22 Jun 2017 08:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KUXqto1yqPFcbMTBgcksqHZnkUOX5knpXPq/ftvu/U0=; b=d34P9+0yN2pKhI80P+BsDgyedk52btYF3F6P4BsT9NhZX5dONZnuS35qdKrKa/XTCd06hRjetLhhyMIJrWvtkbTOuJK4FJqrnvJCGgOYjGFgaPrsj9YktlWvdDjzlEu0waEeI92G5tIjklcLQGw+8SqxNVHiZSgMgIEjJ+j5IGM= Received: from AMSPR05MB296.eurprd05.prod.outlook.com (10.242.95.155) by AMSPR05MB295.eurprd05.prod.outlook.com (10.242.95.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Thu, 22 Jun 2017 15:09:27 +0000 Received: from AMSPR05MB296.eurprd05.prod.outlook.com ([fe80::5841:b79f:bc9e:90af]) by AMSPR05MB296.eurprd05.prod.outlook.com ([fe80::5841:b79f:bc9e:90af%17]) with mapi id 15.01.1178.023; Thu, 22 Jun 2017 15:09:27 +0000 From: David Mozes To: "Frank Brockners (fbrockne)" , Haoyu song , "ippm@ietf.org" , "draft-brockners-inband-oam-data.authors@ietf.org" Thread-Topic: draft on iOAM scalability improvement Thread-Index: AdLTH0fsZe3MoWIbQhuBeTS1CfmKpQWer/5QAHPYiKA= Date: Thu, 22 Jun 2017 15:09:27 +0000 Message-ID: References: <78A2745BE9B57D4F9D27F86655EB87F925845299@SJCEML701-CHM.china.huawei.com> <4f130f2b419445a2a678bc8da745c0a4@XCH-RCD-008.cisco.com> In-Reply-To: <4f130f2b419445a2a678bc8da745c0a4@XCH-RCD-008.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AMSPR05MB295; 7:waZ1a7OhYR9KHQReUR4e8281FDqID4lSissP+WCddx8aZZJfLSHaL/mWMW/3+9WCBDPalygLKd8pmnXXuvhoRHL3knIcgvZPUgmPbqUN+GP5Mp6sZlYadTvGk4QvH6F6O01K4/dMuxV4DFejpt4Vy8BZ3vyWAJuqoV1TVmFloUVrXThmM+PKBOvLT3jPnxTVhQQb4NqC/f6Gnw0HqfxGjYcPSyPf9yHKZZ1GpXJGv71N3UJdrIwS76M4bxnR5JiiukQabfgD2cJDmT8ZvCxc1NEczn1jlZHDcbdjKPSwjzMtSu3dQP2ysDC0KNAbqx1XYZ9u6fv9NMaWNmj3W6SfhmKYPwfE944XVReT3LBKPCmVHJDOiYGG9GXMQ0HATgef+rEAHcDxSjXe3MV62Uvs+ghE/DM3gZc6tJamyLWR2xGs5YIlERsb18EBvFwYK/O5/dk7si3ohmUR7S6K03HVaDLAttIHv+Or5n+GOzxR2Zj8w6EnpAYURKy8KOTK7LRIPdzCivnP4zB3+LZRwv/hcPVmq1qrqvQ5pxtEjXMClJd0Hn2WMoxu9RR7/Da/zPUYrO1UZM2SnS1F1uzTkAVRu7K0V20R0Co/csi7kdBbber0KPwbpUath6d32oYWkjuLCyIZCOIenlBi6YK0QjzzuRxvKio3oBmP68oqcpNbu2NYP2zCoGv1Kj/2h2Mn1TILA6V2gpk+HrwMZN0PVzkKq4G8R197ljReJ7gHIWPt/1QsP69/oJAleOa0Dbg39Y9GmwL9dx0WvavXdPXq+IsB4qRGWhqaAAxoI4OvVsVLMgQ= x-ms-office365-filtering-correlation-id: a953ea0a-ef31-4738-2852-08d4b980ad2b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AMSPR05MB295; x-ms-traffictypediagnostic: AMSPR05MB295: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(189930954265078)(50582790962513)(95692535739014)(45079756050767)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AMSPR05MB295; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AMSPR05MB295; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39400400002)(39410400002)(39850400002)(39840400002)(39860400002)(377454003)(45984002)(76104003)(5250100002)(7906003)(2501003)(25786009)(54896002)(2900100001)(229853002)(7736002)(53546010)(606005)(6506006)(6306002)(6436002)(99286003)(2906002)(189998001)(102836003)(6116002)(5660300001)(8676002)(86362001)(790700001)(2950100002)(3846002)(55016002)(74316002)(50986999)(8936002)(54356999)(76176999)(2201001)(7696004)(478600001)(33656002)(9686003)(53936002)(3660700001)(236005)(3280700002)(966005)(14454004)(66066001)(38730400002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR05MB295; H:AMSPR05MB296.eurprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AMSPR05MB29629DFD945A19EC2A7CCC0B6DB0AMSPR05MB296eurprd_" MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 15:09:27.6759 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR05MB295 Archived-At: Subject: Re: [ippm] draft on iOAM scalability improvement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jun 2017 15:09:36 -0000 --_000_AMSPR05MB29629DFD945A19EC2A7CCC0B6DB0AMSPR05MB296eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi , I think there is an little mistake in the delay record. See below. transit delay: 4-octet unsigned integer in the range 0 to 2^30-1. It is the time in nanoseconds the packet spent in the transit node. This can serve as an indication of the queuing delay at the node. If the transit delay exceeds 2^30-1 nanoseconds then the top bit 'O' is set to indicate overflow. When this field is part of the data field but a node populating the field is not able to fill it, the field position in the field must be filled with value 0xFFFFFFFF to mean not populated. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O| transit delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I think it should be 2^31-1, because otherwise there is always 1 bit that i= s not used. Let me know what do you think Thx David From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, June 20, 2017 10:59 AM To: Haoyu song ; ippm@ietf.org; draft-brockners-inba= nd-oam-data.authors@ietf.org Subject: RE: draft on iOAM scalability improvement Hi Haoyu, thanks for posting this well written draft. While reading the draft, I was = wondering whether you have considered reversing the logic of your draft: Cu= rrently you start with identifying certain perceived "scalability issues" a= nd offering associated solutions, but you only very briefly touch on the us= e-cases that would require those enhancements and don't detail the required= data-fields. Given that the current focus of the work is to define data-fi= elds for IOAM, would it make sense to describe the new use-cases and the re= quired new data-fields first. The WG could then jointly discuss how to best= fit these new data-fields in. Thoughts? Thanks, Frank From: Haoyu song [mailto:haoyu.song@huawei.com] Sent: Montag, 22. Mai 2017 19:23 To: ippm@ietf.org; draft-brockners-inband-oam-data.au= thors@ietf.org Subject: draft on iOAM scalability improvement Dear all, We have submitted an iOAM related draft as follows. Please kindly provide = comments and also let us know if you have any questions which will help us= continue to improve the draft. Thank you very much! https://datatracker.ietf.org/doc/draft-song-ippm-ioam-scalability/ Abstract: This document describes several scalability issues in current in-situ OAM documents and proposes corresponding solutions. Specifically, we extend in-situ OAM to support more standard tracing data than is currently defined and add new features to avoid limitations on MTU, bandwidth, forwarding path length, and node processing capability. Haoyu --_000_AMSPR05MB29629DFD945A19EC2A7CCC0B6DB0AMSPR05MB296eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi  , =

I think there is an li= ttle mistake in the delay record. See below.

 

   transit d= elay:  4-octet unsigned integer in the range 0 to 2^30-1.

   &nbs= p;  It is the time in nanoseconds the packet spent in the transit=

   &nbs= p;  node.  This can serve as an indication of the queuing delay a= t the

   &nbs= p;  node.  If the transit delay exceeds 2^30-1 nanoseconds then t= he

   &nbs= p;  top bit 'O' is set to indicate overflow.  When this field is = part

   &nbs= p;  of the data field but a node populating the field is not able to

   &nbs= p;  fill it, the field position in the field must be filled with value=

   &nbs= p;  0xFFFFFFFF to mean not populated.

 

    0 1= 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

   |O| =             &nb= sp;       transit delay   &nbs= p;            &= nbsp;          |

   +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

 

 

I think it should be 2= ^31-1, because otherwise there is always 1 bit that is not used.=

 

Let me know what do yo= u think

 

Thx<= /p>

David

 

 

From: Frank Brockners (fbrockne) [mailto:fbro= ckne@cisco.com]
Sent: Tuesday, June 20, 2017 10:59 AM
To: Haoyu song <haoyu.song@huawei.com>; ippm@ietf.org; draft-b= rockners-inband-oam-data.authors@ietf.org
Subject: RE: draft on iOAM scalability improvement

 

Hi Haoyu,<= o:p>

 = ;

thanks for posting thi= s well written draft. While reading the draft, I was wondering whether you = have considered reversing the logic of your draft: Currently you start with= identifying certain perceived “scalability issues” and offering associated solutions, but you only very briefly= touch on the use-cases that would require those enhancements and don’= ;t detail the required data-fields. Given that the current focus of the wor= k is to define data-fields for IOAM, would it make sense to describe the new use-cases and the required new data-fields = first. The WG could then jointly discuss how to best fit these new data-fie= lds in.

 

Thoughts?

 

Thanks, Fr= ank

 = ;

From: Haoyu song [mailto:haoyu.song@huawei.com]
Sent: Montag, 22. Mai 2017 19:23
To: ippm@ietf.org; draft-brockners-inband-oam-data.authors@ietf.org
Subject: draft on iOAM scalability improvement

 

Dear all,

 

We have submitted an iOAM related draft as follows. =  Please kindly provide  comments and also let us know if you have= any questions which will help us continue to improve the draft. Thank you = very much!

 

https://datatracker.ietf.org/doc/draft-song-ippm-ioam-scalabi= lity/

 

Abstract:

   This document describes several scal= ability issues in current in-situ

   OAM documents and proposes correspon= ding solutions.  Specifically, we

   extend in-situ OAM to support more s= tandard tracing data than is

   currently defined and add new featur= es to avoid limitations on MTU,

   bandwidth, forwarding path length, a= nd node processing capability.

 

 

Haoyu

        &nbs= p;            &= nbsp;   

--_000_AMSPR05MB29629DFD945A19EC2A7CCC0B6DB0AMSPR05MB296eurprd_-- From nobody Thu Jun 22 19:42:55 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054EF12704A; Thu, 22 Jun 2017 19:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zcMP90CMJ6gh; Thu, 22 Jun 2017 19:42:51 -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 7E6C91200E5; Thu, 22 Jun 2017 19:42:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPR07172; Fri, 23 Jun 2017 02:42:48 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 23 Jun 2017 03:42:46 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 23 Jun 2017 10:42:31 +0800 From: Tianran Zhou To: David Mozes , "Frank Brockners (fbrockne)" , Haoyu song , "ippm@ietf.org" , "draft-brockners-inband-oam-data.authors@ietf.org" Thread-Topic: draft on iOAM scalability improvement Thread-Index: AdLTH0fsZe3MoWIbQhuBeTS1CfmKpQWer/5QAHPYiKAAF1lAsA== Date: Fri, 23 Jun 2017 02:42:31 +0000 Message-ID: References: <78A2745BE9B57D4F9D27F86655EB87F925845299@SJCEML701-CHM.china.huawei.com> <4f130f2b419445a2a678bc8da745c0a4@XCH-RCD-008.cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21A23AF7BANKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.594C8028.0106, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a22c5299bc5b8ae6a65e2ddd07351373 Archived-At: Subject: Re: [ippm] draft on iOAM scalability improvement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 23 Jun 2017 02:42:54 -0000 --_000_BBA82579FD347748BEADC4C445EA0F21A23AF7BANKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have some suggestions on existing time related data fields. 1. The timestamp, for example the "timestamp seconds", is "absolute timesta= mp in seconds that specifies the time at which the packet was received by t= he node." So does this mean the timestamp is taken at the ingress? If so, i= t's worth to explicitly name it "ingress timestamp" or so. So that every de= vice can have the identical behavior to take the timestamp to, for example,= calculate the hop by hop delay. 2. The "transit delay", IMHO, is not easy to calculate in some devices, bec= ause of the architecture limitation. If we want to get this information, we= can record the "egress timestamp" relative to the "ingress timestamp". The= n, the transit delay can be calculated at any position that device can do t= his. Thanks, Tianran From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of David Mozes Sent: Thursday, June 22, 2017 11:09 PM To: Frank Brockners (fbrockne); Haoyu song; ippm@ietf.org; draft-brockners-= inband-oam-data.authors@ietf.org Subject: Re: [ippm] draft on iOAM scalability improvement Hi , I think there is an little mistake in the delay record. See below. transit delay: 4-octet unsigned integer in the range 0 to 2^30-1. It is the time in nanoseconds the packet spent in the transit node. This can serve as an indication of the queuing delay at the node. If the transit delay exceeds 2^30-1 nanoseconds then the top bit 'O' is set to indicate overflow. When this field is part of the data field but a node populating the field is not able to fill it, the field position in the field must be filled with value 0xFFFFFFFF to mean not populated. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O| transit delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I think it should be 2^31-1, because otherwise there is always 1 bit that i= s not used. Let me know what do you think Thx David From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, June 20, 2017 10:59 AM To: Haoyu song >; ippm@= ietf.org; draft-brockners-inband-oam-data.authors@iet= f.org Subject: RE: draft on iOAM scalability improvement Hi Haoyu, thanks for posting this well written draft. While reading the draft, I was = wondering whether you have considered reversing the logic of your draft: Cu= rrently you start with identifying certain perceived "scalability issues" a= nd offering associated solutions, but you only very briefly touch on the us= e-cases that would require those enhancements and don't detail the required= data-fields. Given that the current focus of the work is to define data-fi= elds for IOAM, would it make sense to describe the new use-cases and the re= quired new data-fields first. The WG could then jointly discuss how to best= fit these new data-fields in. Thoughts? Thanks, Frank From: Haoyu song [mailto:haoyu.song@huawei.com] Sent: Montag, 22. Mai 2017 19:23 To: ippm@ietf.org; draft-brockners-inband-oam-data.au= thors@ietf.org Subject: draft on iOAM scalability improvement Dear all, We have submitted an iOAM related draft as follows. Please kindly provide = comments and also let us know if you have any questions which will help us= continue to improve the draft. Thank you very much! https://datatracker.ietf.org/doc/draft-song-ippm-ioam-scalability/ Abstract: This document describes several scalability issues in current in-situ OAM documents and proposes corresponding solutions. Specifically, we extend in-situ OAM to support more standard tracing data than is currently defined and add new features to avoid limitations on MTU, bandwidth, forwarding path length, and node processing capability. Haoyu --_000_BBA82579FD347748BEADC4C445EA0F21A23AF7BANKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have some suggestions on ex= isting time related data fields.

 

1. The timestamp, for example= the “timestamp seconds”, is “absolute timestamp in secon= ds that specifies the time at which the packet was received by the node.” So does this mean the timestamp = is taken at the ingress? If so, it’s worth to explicitly name it R= 20;ingress timestamp” or so. So that every device can have the identi= cal behavior to take the timestamp to, for example, calculate the hop by hop delay.

 

2. The “transit delay&#= 8221;, IMHO, is not easy to calculate in some devices, because of the archi= tecture limitation. If we want to get this information, we can record the “egress timestamp” relative to the “ingress t= imestamp”. Then, the transit delay can be calculated at any position = that device can do this.

 

Thanks,

Tianran

 

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of David Mozes
Sent: Thursday, June 22, 2017 11:09 PM
To: Frank Brockners (fbrockne); Haoyu song; ippm@ietf.org; draft-bro= ckners-inband-oam-data.authors@ietf.org
Subject: Re: [ippm] draft on iOAM scalability improvement=

 

Hi = ; ,

I think= there is an little mistake in the delay record. See below.

&n= bsp;

 &= nbsp; transit delay:  4-octet unsigned integer in the range 0 to 2^30-= 1.

 &= nbsp;    It is the time in nanoseconds the packet spent in t= he transit

 &= nbsp;    node.  This can serve as an indication of the = queuing delay at the

 &= nbsp;    node.  If the transit delay exceeds 2^30-1 nan= oseconds then the

 &= nbsp;    top bit 'O' is set to indicate overflow.  When= this field is part

 &= nbsp;    of the data field but a node populating the field i= s not able to

 &= nbsp;    fill it, the field position in the field must be fi= lled with value

 &= nbsp;    0xFFFFFFFF to mean not populated.=

&n= bsp;

 &= nbsp;  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=

 &= nbsp; +-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+

 &= nbsp; |O|           =           transit delay &= nbsp;           &nbs= p;             = |

 &= nbsp; +-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+

&n= bsp;

&n= bsp;

I think= it should be 2^31-1, because otherwise there is always 1 bit that is not u= sed.

&n= bsp;

Let me = know what do you think

&n= bsp;

Thx

David <= o:p>

&n= bsp;

&n= bsp;

From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com]
Sent: Tuesday, June 20, 2017 10:59 AM
To: Haoyu song <haoyu.so= ng@huawei.com>; ippm@ietf.org; draft-brockners-inband-oam-data.authors@ietf.org
Subject: RE: draft on iOAM scalability improvement=

 

Hi Haoyu,<= o:p>

 = ;

thanks = for posting this well written draft. While reading the draft, I was wonderi= ng whether you have considered reversing the logic of your draft: Currently= you start with identifying certain perceived “scalability issues” and offering associated solutions, but yo= u only very briefly touch on the use-cases that would require those enhance= ments and don’t detail the required data-fields. Given that the curre= nt focus of the work is to define data-fields for IOAM, would it make sense to describe the new use-cases and the required n= ew data-fields first. The WG could then jointly discuss how to best fit the= se new data-fields in.

&n= bsp;

Thought= s?

&n= bsp;

Thanks, Fr= ank

 = ;

From: Haoyu song [mailto:hao= yu.song@huawei.com]
Sent: Montag, 22. Mai 2017 19:23
To: ippm@ietf.org; draft-brockners-inband-oam-data.authors@ietf.org
Subject: draft on iOAM scalability improvement

 

Dear all,

 

We have submitted an iOAM relat= ed draft as follows.  Please kindly provide  comments and also le= t us know if you have any questions which will help us continue to improve = the draft. Thank you very much!

 

https://datatracker.ietf.org/doc/draft-s= ong-ippm-ioam-scalability/

 

Abstract:<= /p>

   This document d= escribes several scalability issues in current in-situ

   OAM documents a= nd proposes corresponding solutions.  Specifically, we

   extend in-situ = OAM to support more standard tracing data than is

   currently defin= ed and add new features to avoid limitations on MTU,

   bandwidth, forw= arding path length, and node processing capability.

 

 

Haoyu

     &= nbsp;           &nbs= p;       

--_000_BBA82579FD347748BEADC4C445EA0F21A23AF7BANKGEML515MBXchi_-- From nobody Fri Jun 23 10:20:04 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E84129601; Fri, 23 Jun 2017 10:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 aYM-EEQxzqOb; Fri, 23 Jun 2017 10:20:00 -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 C7A14127333; Fri, 23 Jun 2017 10:19:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJB83708; Fri, 23 Jun 2017 17:19:56 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 23 Jun 2017 18:19:55 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000; Fri, 23 Jun 2017 10:19:43 -0700 From: Haoyu song To: Tianran Zhou , David Mozes , "Frank Brockners (fbrockne)" , "ippm@ietf.org" , "draft-brockners-inband-oam-data.authors@ietf.org" Thread-Topic: draft on iOAM scalability improvement Thread-Index: AdLTH0fsZe3MoWIbQhuBeTS1CfmKpQWer/5QAHPYiKAAF1lAsAAfMXzA Date: Fri, 23 Jun 2017 17:19:43 +0000 Message-ID: <78A2745BE9B57D4F9D27F86655EB87F9259555C8@SJCEML702-CHM.china.huawei.com> References: <78A2745BE9B57D4F9D27F86655EB87F925845299@SJCEML701-CHM.china.huawei.com> <4f130f2b419445a2a678bc8da745c0a4@XCH-RCD-008.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.217.119] Content-Type: multipart/alternative; boundary="_000_78A2745BE9B57D4F9D27F86655EB87F9259555C8SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.594D4DBD.006F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 13a0c1d0bcaa62f7376adfb679cef4e0 Archived-At: Subject: Re: [ippm] draft on iOAM scalability improvement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 23 Jun 2017 17:20:02 -0000 --_000_78A2745BE9B57D4F9D27F86655EB87F9259555C8SJCEML702CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. There is a tradeoff between node processing overhead and data carr= y overhead. It makes sense to define both of them and let user decide which= data type is used based on their actual network situation. Besides, the last improvement we introduced in the following draft, the "va= lid data bitmap" allows each node to decide which data to provide, if the s= ource asks for both. https://datatracker.ietf.org/doc/draft-song-ippm-ioam-scalability/ Haoyu From: Tianran Zhou Sent: Thursday, June 22, 2017 7:43 PM To: David Mozes ; Frank Brockners (fbrockne) ; Haoyu song ; ippm@ietf.org; draft-brock= ners-inband-oam-data.authors@ietf.org Subject: RE: draft on iOAM scalability improvement Hi, I have some suggestions on existing time related data fields. 1. The timestamp, for example the "timestamp seconds", is "absolute timesta= mp in seconds that specifies the time at which the packet was received by t= he node." So does this mean the timestamp is taken at the ingress? If so, i= t's worth to explicitly name it "ingress timestamp" or so. So that every de= vice can have the identical behavior to take the timestamp to, for example,= calculate the hop by hop delay. 2. The "transit delay", IMHO, is not easy to calculate in some devices, bec= ause of the architecture limitation. If we want to get this information, we= can record the "egress timestamp" relative to the "ingress timestamp". The= n, the transit delay can be calculated at any position that device can do t= his. Thanks, Tianran From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of David Mozes Sent: Thursday, June 22, 2017 11:09 PM To: Frank Brockners (fbrockne); Haoyu song; ippm@ietf.org; draft-brockners-inband-oam-data.authors@ietf.org Subject: Re: [ippm] draft on iOAM scalability improvement Hi , I think there is an little mistake in the delay record. See below. transit delay: 4-octet unsigned integer in the range 0 to 2^30-1. It is the time in nanoseconds the packet spent in the transit node. This can serve as an indication of the queuing delay at the node. If the transit delay exceeds 2^30-1 nanoseconds then the top bit 'O' is set to indicate overflow. When this field is part of the data field but a node populating the field is not able to fill it, the field position in the field must be filled with value 0xFFFFFFFF to mean not populated. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O| transit delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I think it should be 2^31-1, because otherwise there is always 1 bit that i= s not used. Let me know what do you think Thx David From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, June 20, 2017 10:59 AM To: Haoyu song >; ippm@= ietf.org; draft-brockners-inband-oam-data.authors@iet= f.org Subject: RE: draft on iOAM scalability improvement Hi Haoyu, thanks for posting this well written draft. While reading the draft, I was = wondering whether you have considered reversing the logic of your draft: Cu= rrently you start with identifying certain perceived "scalability issues" a= nd offering associated solutions, but you only very briefly touch on the us= e-cases that would require those enhancements and don't detail the required= data-fields. Given that the current focus of the work is to define data-fi= elds for IOAM, would it make sense to describe the new use-cases and the re= quired new data-fields first. The WG could then jointly discuss how to best= fit these new data-fields in. Thoughts? Thanks, Frank From: Haoyu song [mailto:haoyu.song@huawei.com] Sent: Montag, 22. Mai 2017 19:23 To: ippm@ietf.org; draft-brockners-inband-oam-data.au= thors@ietf.org Subject: draft on iOAM scalability improvement Dear all, We have submitted an iOAM related draft as follows. Please kindly provide = comments and also let us know if you have any questions which will help us= continue to improve the draft. Thank you very much! https://datatracker.ietf.org/doc/draft-song-ippm-ioam-scalability/ Abstract: This document describes several scalability issues in current in-situ OAM documents and proposes corresponding solutions. Specifically, we extend in-situ OAM to support more standard tracing data than is currently defined and add new features to avoid limitations on MTU, bandwidth, forwarding path length, and node processing capability. Haoyu --_000_78A2745BE9B57D4F9D27F86655EB87F9259555C8SJCEML702CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree. There is a tr= adeoff between node processing overhead and data carry overhead. It makes s= ense to define both of them and let user decide which data type is used bas= ed on their actual network situation.

Besides, the last improvement we introduced in the following draft, the “valid= data bitmap” allows each node to decide which data to provide, if th= e source asks for both.

https://datatracker.ietf.org/doc/draft-song-ippm= -ioam-scalability/

 

Haoyu

From: Tianran Zhou
Sent: Thursday, June 22, 2017 7:43 PM
To: David Mozes <davidm@mellanox.com>; Frank Brockners (fbrock= ne) <fbrockne@cisco.com>; Haoyu song <haoyu.song@huawei.com>; i= ppm@ietf.org; draft-brockners-inband-oam-data.authors@ietf.org
Subject: RE: draft on iOAM scalability improvement

 

Hi,

 

I have some suggestions on existing time rel= ated data fields.

 

1. The timestamp, for example the “tim= estamp seconds”, is “absolute timestamp in seconds that specifi= es the time at which the packet was received by the node.” So does this mean the timestamp = is taken at the ingress? If so, it’s worth to explicitly name it R= 20;ingress timestamp” or so. So that every device can have the identi= cal behavior to take the timestamp to, for example, calculate the hop by hop delay.

 

2. The “transit delay”, IMHO, is= not easy to calculate in some devices, because of the architecture limitat= ion. If we want to get this information, we can record the “egress timestamp” relative to the “ingress timestamp= 221;. Then, the transit delay can be calculated at any position that device= can do this.

 

Thanks,

Tianran

 

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of David Mozes
Sent: Thursday, June 22, 2017 11:09 PM
To: Frank Brockners (fbrockne); Haoyu song; ippm@ietf.org; draft-brockners-inband-oam-data.authors@ietf.org
Subject: Re: [ippm] draft on iOAM scalability improvement=

 

Hi  , =

I think there is an li= ttle mistake in the delay record. See below.

 

   transit d= elay:  4-octet unsigned integer in the range 0 to 2^30-1.

   &nbs= p;  It is the time in nanoseconds the packet spent in the transit=

   &nbs= p;  node.  This can serve as an indication of the queuing delay a= t the

   &nbs= p;  node.  If the transit delay exceeds 2^30-1 nanoseconds then t= he

   &nbs= p;  top bit 'O' is set to indicate overflow.  When this field is = part

   &nbs= p;  of the data field but a node populating the field is not able to

   &nbs= p;  fill it, the field position in the field must be filled with value=

   &nbs= p;  0xFFFFFFFF to mean not populated.

 

    0 1= 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

   |O| =             &nb= sp;       transit delay   &nbs= p;            &= nbsp;          |

   +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

 

 

I think it should be 2= ^31-1, because otherwise there is always 1 bit that is not used.=

 

Let me know what do yo= u think

 

Thx<= /p>

David

 

 

From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com]
Sent: Tuesday, June 20, 2017 10:59 AM
To: Haoyu song <haoyu.so= ng@huawei.com>; ippm@ietf.org; draft-brockners-inband-oam-data.authors@ietf.org
Subject: RE: draft on iOAM scalability improvement

 

Hi Haoyu,<= o:p>

 = ;

thanks for posting thi= s well written draft. While reading the draft, I was wondering whether you = have considered reversing the logic of your draft: Currently you start with= identifying certain perceived “scalability issues” and offering associated solutions, but you only very briefly= touch on the use-cases that would require those enhancements and don’= ;t detail the required data-fields. Given that the current focus of the wor= k is to define data-fields for IOAM, would it make sense to describe the new use-cases and the required new data-fields = first. The WG could then jointly discuss how to best fit these new data-fie= lds in.

 

Thoughts?

 

Thanks, Fr= ank

 = ;

From: Haoyu song [mailto:haoyu.song@huawei.com]
Sent: Montag, 22. Mai 2017 19:23
To: ippm@ietf.org; draft-brockners-inband-oam-data.authors@ietf.org
Subject: draft on iOAM scalability improvement

 

Dear all,

 

We have submitted an iOAM related draft as follows. =  Please kindly provide  comments and also let us know if you have= any questions which will help us continue to improve the draft. Thank you = very much!

 

https://datatracker.ietf.org/doc/draft-song-ippm-ioam-scalabi= lity/

 

Abstract:

   This document describes several scal= ability issues in current in-situ

   OAM documents and proposes correspon= ding solutions.  Specifically, we

   extend in-situ OAM to support more s= tandard tracing data than is

   currently defined and add new featur= es to avoid limitations on MTU,

   bandwidth, forwarding path length, a= nd node processing capability.

 

 

Haoyu

        &nbs= p;            &= nbsp;   

--_000_78A2745BE9B57D4F9D27F86655EB87F9259555C8SJCEML702CHMchi_-- From nobody Fri Jun 23 17:07:55 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C09381294AC; Fri, 23 Jun 2017 17:06:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: spencerdawkins.ietf@gmail.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826281878.7840.15061875522813618720.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:06:58 -0700 Archived-At: Subject: [ippm] ippm - Requested session has been scheduled for IETF 99 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:06:59 -0000 Dear Brian Trammell, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ippm Session 1 (2:00:00) Wednesday, Morning Session I 0930-1200 Room Name: Athens/Barcelona size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IP Performance Metrics Area Name: Transport Area Session Requester: Brian Trammell Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: tsvarea tsvwg tcpm taps bmwg lmap xrblock quic Second Priority: v6ops 6man 6lo sunset4 opsec tcpinc Third Priority: cdni alto People who must be present: Al Morton Frank Brockners Spencer Dawkins Brian Trammell Bill Cerveny Kostas Pentikousis Giuseppe Fioccola Resources Requested: Special Requests: Please try not to schedule opposite irtfopen, iccrg, maprg. Do not schedule opposite panrg (hard conflict with chair) --------------------------------------------------------- From nobody Sun Jun 25 12:09:18 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED60C120726; Sun, 25 Jun 2017 12:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9Q9KiA9k-aRC; Sun, 25 Jun 2017 12:09:14 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA0A1200FC; Sun, 25 Jun 2017 12:09:14 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id 84so23836736ybe.0; Sun, 25 Jun 2017 12:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MP0qI9wb2rzTBz5AHkbBLPI9x0WPcoojKZo0izWq++Y=; b=Vxj6U3c2ccx0c4V5uchFhoNPoI0FRn4b67WID+wkLQey0bPnvIGXmetO7G4NtXPdaY L02jHVUaO+yejXkC07L1ZwUks2190li8mDpbTUsksHWFJ3hhftVPkyCHiIIc6h5h/WZw W4q2HG4aKhZ/fC+U5SSy0zpzUXjRbx/j6lX9SvqmdcFILxaDl55o37QibtiA+jyZhrIF tjDLVjceR5wO/GRGkmjxmmbBcOmPV4I5koabpvv/IJ2c8oyMTodbQjODj7p5QfG2X/Hx xvIyXflD9lQMyTom2kasFnLW7n5SPaCNL0HTlXAJZ5wDdMUYtv56OXK5G+3tzDHQKMcW OSwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MP0qI9wb2rzTBz5AHkbBLPI9x0WPcoojKZo0izWq++Y=; b=dMWjhXTb/eZC316qbbUG465rOrCuVgCxQ/a7asmTqKtfx2PKt6955lT8q7uNDE1/EC uBVfIt7DQlRqd3QKeUKw6AF6sM2UMNAV74Rvz4EfrEEzx9Bql1AixvfjMjHzu+B90/Ov cQhcUBN8wN8hErmHi61NKTvSK2e8g47kqHunYaDAnS1XHKSyEpZXEx/ykzkOMBII3aKL wKog7GMDaP9YVnxKgv89OS6hwCb4LpLG4XAbcvR0rLGo5Lnn4sib5RYxm56XqT8jTPKQ XVSiWD/F1a7EZd7+rgqidTEv3RSdntVX43Zb8DRS3pweHYvSlAajhTz13Xu7G+AVfrzx 0wkA== X-Gm-Message-State: AKS2vOwmMpyA/buhBhlfRC9/JQkchHzxSN0k+g5CYSR4qIYdvau41/Xa Q1NnNuzjkospEGMOcIA66PeuXu6LKA== X-Received: by 10.37.204.138 with SMTP id l132mr12744664ybf.176.1498417753451; Sun, 25 Jun 2017 12:09:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.104.144 with HTTP; Sun, 25 Jun 2017 12:09:13 -0700 (PDT) In-Reply-To: <922169529.4233696.1495466806431@mail.yahoo.com> References: <149200885746.15718.798617550888585150.idtracker@ietfa.amsl.com> <922169529.4233696.1495466806431@mail.yahoo.com> From: Spencer Dawkins at IETF Date: Sun, 25 Jun 2017 14:09:13 -0500 Message-ID: To: Nalini J Elkins Cc: Alissa Cooper , The IESG , "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , "acmorton@att.com" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c075b32eb7bef0552cd912a" Archived-At: Subject: Re: [ippm] Alissa Cooper's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 19:09:17 -0000 --94eb2c075b32eb7bef0552cd912a Content-Type: text/plain; charset="UTF-8" Hi, Alissa, On Mon, May 22, 2017 at 10:26 AM, Nalini J Elkins < nalini.elkins@insidethestack.com> wrote: > Alissa, > > Please let me know if you are OK with the proposed change. > The change looks OK to me, but I'm not the expert on this. Could you let us know what you think? Thanks, Spencer > > > > > >Alissa Cooper has entered the following ballot position for > >draft-ietf-ippm-6man-pdm-option-09: No Objection > > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > >for more information about IESG DISCUSS and COMMENT positions. > > > >The document, along with other ballot positions, can be found here: > >https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ > > > > >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > > >The analysis in Sec 4.2 seems to be missing some considerations. In cases > >where the packet payload is encrypted and the attacker does not have > >access to the keys, the attacker does not in fact have access to the > >entire packet, in which case PDM provides more information than a packet > >without PDM. Also in those cases, it seems like including PDM information > >would generally make a packet stream more susceptible to traffic analysis > >insofar as the timing and sequence information may provide additional > >indicators about the type of application in use, not just the speed of > >the end host. > > > Are you OK if I do the following: > > > OLD > ------ > Since PDM passes in the clear, a concern arises as to whether the > data can be used to fingerprint the system or somehow obtain > information about the contents of the payload. > > Let us discuss fingerprinting of the end host first. It is possible > that seeing the pattern of deltas or the absolute values could give > some information as to the speed of the end host - that is, if it is > a very fast system or an older, slow device. This may be useful to > the attacker. However, if the attacker has access to PDM, the > attacker also has access to the entire packet and could make such a > deduction based merely on the time frames elapsed between packets > WITHOUT PDM. > > As far as deducing the content of the payload, it appears to us that > PDM is quite unhelpful in this regard. > > > > New > ------ > > Since PDM passes in the clear, a concern arises as to whether the > data can be used to fingerprint the system or somehow obtain > information about the contents of the payload. > > Let us discuss fingerprinting of the end host first. It is possible > that seeing the pattern of deltas or the absolute values could give > some information as to the speed of the end host - that is, if it is > a very fast system or an older, slow device. This may be useful to > the attacker. However, if the attacker has access to PDM, the > attacker also has access to the entire packet and could make such a > deduction based merely on the time frames elapsed between packets > WITHOUT PDM. > > As far as deducing the content of the payload, it is conceivable > that an attacker could attempt to deduce the type of application in > use by noting the server time and payload length. Having said that, > some encryption algorithms attempt to obfuscate the packet length > to avoid just such vulnerabilities. In the future, encryption algorithms > may wish to obfuscate the server time as well. > > > > --94eb2c075b32eb7bef0552cd912a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Alissa,

On Mon, May 22, 2017 at 10:26 AM, Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:
Al= issa,

Please let me know if you are OK with the proposed change.
=

The change looks OK to me, but= I'm not the expert on this. Could you let us know what you think?

Thanks,

Spencer
=C2= =A0




>Alissa Cooper has en= tered the following ballot position for
>draft-ietf-ippm-6man-pdm-opti= on-09: No Objection


>for more informa= tion about IESG DISCUSS and COMMENT positions.


>The document, along with ot= her ballot positions, can be found here:



>---------------------------= -------------------------------------------
>COMMENT:
>----------= ------------------------------------------------------------
<= /div>

>The a= nalysis in Sec 4.2 seems to be missing some considerations. In cases
>where= the packet payload is encrypted and the attacker does not have
>access to = the keys, the attacker does not in fact have access to the
>entire packet, = in which case PDM provides more information than a packet
>without PDM. Als= o in those cases, it seems like including PDM information
>would generally = make a packet stream more susceptible to traffic analysis
>insofar as the t= iming and sequence information may provide additional
>indicators about the= type of application in use, not just the speed of
>the end host.
=


Are you OK if I do = the following:


OLD
------
=C2=A0Since = PDM passes in the clear, a concern arises as to whether the
=C2=A0data can be used to fingerprint the system or somehow obtain=
=C2=A0information about the contents of the payloa= d. =C2=A0

=C2=A0Let us discuss f= ingerprinting of the end host first. It is possible
=C2=A0that seeing the pattern of deltas or the absolute values could give<= /font>
=C2=A0some information as to the speed of the end h= ost - that is, if it is
=C2=A0a very fast system or= an older, slow device. =C2=A0 This may be useful to
<= font face=3D"HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande= , sans-serif" id=3D"m_7529968829983582754yui_3_16_0_ym19_1_1495466060991_69= 98">=C2=A0the attacker.=C2=A0 However, if the attacker has access to PDM, t= he
=C2=A0attacker also has access to the entire pac= ket and could make such a
=C2=A0deduction based mer= ely on the time frames elapsed between packets
=C2= =A0WITHOUT PDM. =C2=A0

=C2= =A0As far as deducing the content of the payload, it appears to us that
=C2=A0PDM is quite unhelpful in this regard.



New
------

Since PDM passes in = the clear, a concern arises as to whether the
= data can be used to fingerprint the system or somehow obtain
information about the contents of the payload. =C2=A0

Let us discuss fingerprinting of the end ho= st first. It is possible
that seeing the pattern of= deltas or the absolute values could give
some = information as to the speed of the end host - that is, if it is
a very fast system or an older, slow device. =C2=A0 This may b= e useful to
the attacker.=C2=A0 However, if the att= acker has access to PDM, the
attacker also has acce= ss to the entire packet and could make such a
deduc= tion based merely on the time frames elapsed between packets
WITHOUT PDM. =C2=A0

As= far as deducing the content of the payload, it is conceivable
=
that an attacker could attempt to deduce the type of applicatio= n in
use by noting the server time and payload leng= th. =C2=A0 Having said that,
some encryption algori= thms attempt to obfuscate the=C2=A0packet length
t= o avoid just such vulnerabilities.=C2=A0 In the future, encryption algorith= ms
may wi= sh to obfuscate the server time as well. =C2=A0



=

--94eb2c075b32eb7bef0552cd912a-- From nobody Sun Jun 25 12:12:00 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59F41204DA; Sun, 25 Jun 2017 12:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 c2V2UwU-uJ58; Sun, 25 Jun 2017 12:11:49 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A9A1200FC; Sun, 25 Jun 2017 12:11:49 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id 63so30785258ywr.0; Sun, 25 Jun 2017 12:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mCOV26Audp076peL8Laao7LVqHWC2DHNyIFHT4FpOws=; b=JPJoHpYBM/7y0bS8QfqfngKBulexkmDvLwL3Aerx5y+lVIYQRrzpdWxQtcI78nkQBk T/Sc1Eh7yADnXrSb7Eji8tiG3uiWC1WVwVYSrH35L6WfHXyRK8Snl/6QXfndMJ8Ay6mO KBPtdgTruXCkltoreGurX6gk2W9OUN5CflKw5EtsDXH9KGOtqMLBn9n+PvEvsoZvehW4 ZENnYhX8R64uS/zrBPho04dVmQWKSUb2mL8SHBewyj55k7jWtWJyt5FfooLB1sqeEUg6 JmLJXigHFn+ApcPKvEKX501/qRlTGbRbu4k/s5ZVJ/T7sxpQFvCseDJKT+5Ha2sYixLV /8Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mCOV26Audp076peL8Laao7LVqHWC2DHNyIFHT4FpOws=; b=YRc0QKcBLDkSdVtHzv12kOM3y1AzebKknMEU/rVMZonHnuDY8Q0nbRUFTSHRBkJicf D1EJ8zSXev1tS4pgBTIvxGw/cr3aLC83a3TT1Kty/LiULcaTOq/FeDNFwTV+jI2OgVhM dtXsDM+3is1aqt6qSBgJpbeV+/snSdPMO8QxzjlcGnTbpEmu9zx96wTjA1af+ge9XrKW Hl5kJ3XvMNX6eqVnluGbu2xdF5PFCw75SDLk7jkbzEMeESeu1F7gRfS10WoAxW63zWu2 nnDWystVwPms/5CfEyhmiob3ZgOsaALeqawaAsvUHMjOaUekfi36c+AqZA5w2lgvc1Zb rQAw== X-Gm-Message-State: AKS2vOyT4HDv5LP5vDhX4u3ugEPX/wQWP+iIaYYDdispBQV0D0xATTHy Di3mz9+8ob3QuT27GSVFWar7BRIm2g== X-Received: by 10.129.57.137 with SMTP id g131mr13149696ywa.275.1498417908860; Sun, 25 Jun 2017 12:11:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.104.144 with HTTP; Sun, 25 Jun 2017 12:11:48 -0700 (PDT) In-Reply-To: <1119101915.4268397.1495467658355@mail.yahoo.com> References: <149195586781.15796.5030067129991289423.idtracker@ietfa.amsl.com> <1119101915.4268397.1495467658355@mail.yahoo.com> From: Spencer Dawkins at IETF Date: Sun, 25 Jun 2017 14:11:48 -0500 Message-ID: To: Nalini J Elkins Cc: Eric Rescorla , The IESG , "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , Al Morton , "ippm@ietf.org" Content-Type: multipart/alternative; boundary="001a114c8a822ed0aa0552cd9bc1" Archived-At: Subject: Re: [ippm] Eric Rescorla's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 19:11:53 -0000 --001a114c8a822ed0aa0552cd9bc1 Content-Type: text/plain; charset="UTF-8" Hi, Nalini, On Mon, May 22, 2017 at 10:40 AM, Nalini J Elkins < nalini.elkins@insidethestack.com> wrote: > > > >Eric Rescorla has entered the following ballot position for > draft-ietf-ippm-6man-pdm-option-09: No Objection > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > >for more information about IESG DISCUSS and COMMENT positions. > > > >The document, along with other ballot positions, can be found here: > >https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ > > > >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > > >I think the description of timing attacks could use a bit more work. > > >Specifically: > > >- I am assuming that you should discard rather than using as timestamp > > sources packets which fail ESP. This shouldn't be an issue for > > transport mode because you process ESP first, but in tunnel mode > > you allow either order, so it's a potential issue. > > > I believe some of this is addressed in section 4.3. I can add that the > destination host may also wish to look at this behavior and to > discard such packets. > > > OLD > ------ > > 4.3 PDM as a Covert Channel > > PDM provides a set of fields in the packet which could be used to > leak data. But, there is no real reason to suspect that PDM would > be chosen rather than another part of the payload or another > Extension Header. > > A firewall or another device could sanity check the fields within the > PDM but randomly assigned sequence numbers and delta times might be > expected to vary widely. The biggest problem though is how an > attacker would get access to PDM in the first place to leak data. > The attacker would have to either compromise the end host or have Man > in the Middle (MitM). It is possible that either one could change > the fields. But, then the other end host would get sequence numbers > and deltas that don't make any sense. > > It is conceivable that someone could compromise an end host and make > it start sending packets with PDM without the knowledge of the host. > But, again, the bigger problem is the compromise of the end host. > Once that is done, the attacker probably has better ways to leak > data. > > Having said that, if a PDM aware middle box or an implementation > detects some number of "nonsensical" sequence numbers it could take > action to block (or alert on) this traffic. > > > New > ------ > > 4.3 PDM as a Covert Channel > > PDM provides a set of fields in the packet which could be used to > leak data. But, there is no real reason to suspect that PDM would > be chosen rather than another part of the payload or another > Extension Header. > > A firewall or another device could sanity check the fields within the > PDM but randomly assigned sequence numbers and delta times might be > expected to vary widely. The biggest problem though is how an > attacker would get access to PDM in the first place to leak data. > The attacker would have to either compromise the end host or have Man > in the Middle (MitM). It is possible that either one could change > the fields. But, then the other end host would get sequence numbers > and deltas that don't make any sense. > > It is conceivable that someone could compromise an end host and make > it start sending packets with PDM without the knowledge of the host. > But, again, the bigger problem is the compromise of the end host. > Once that is done, the attacker probably has better ways to leak > data. > > Having said that, if a PDM aware middle box or an implementation > (destination > host) detects some number of "nonsensical" sequence numbers or timing > information, it could take action to block, discard, or alert on this > traffic. > > > > >- It seems like you could use this technique for fine-grained > > timing of the cryptographic operations traffic keys as well (cf. Lucky > 13), > > not just long-term keys as you say in S 4.4. > > > Note that both of these attacks are not ameliorated by restricting > > to host and ports because one assumes that the attacker controls > > the network per 3552 > > I can change the language in section 4.4 as follows: > > Old > ---- > Depending on the nature of the cryptographic protocol used, it may be > possible to leak the long term credentials of the device. For > example, if an attacker is able to create an attack which causes the > enterprise to turn on PDM to diagnose the attack, then the attacker > might use PDM during that debugging time to launch a timing attack > against the long term keying material used by the cryptographic > protocol. > > New > ---- > Depending on the nature of the cryptographic protocol used, it may be > possible to leak the credentials of the device. For > example, if an attacker is able to create an attack which causes the > enterprise to turn on PDM to diagnose the attack, then the attacker > might use PDM during that debugging time to launch a timing attack > against the keying material used by the cryptographic protocol. > I'm not seeing this text in -12. Did I miss it? Spencer > > > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > --001a114c8a822ed0aa0552cd9bc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Nalini,

On Mon, May 22, 2017 at 10:40 AM, Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:


>Eric Rescorla has en= tered the following ballot position for=C2=A0draft-ietf-ippm-6man-pdm-option-09: No Objection=
>for more information abo= ut IESG DISCUSS and COMMENT positions.


>The document, along with other ballot p= ositions, can be found here:


>---------------------------= -------------------------------------------
>COMMENT:
>----------= ------------------------------------------------------------
<= /div>

>I thi= nk the description of timing attacks could use a bit more work.

>Specifically= :
<= br>
>= ;- I am assuming that you should discard rather than using as timestamp
=
> = =C2=A0sources packets which fail ESP. This shouldn't be an issue for
> = =C2=A0transport mode because you process ESP first, but in tunnel mode
<= /div>
> = =C2=A0you allow either order, so it's a potential issue.


I belie= ve some of this is addressed in section 4.3. =C2=A0 I can add that the
destination= host may also wish to look at this behavior and to=C2=A0
discard such packets. = =C2=A0=C2=A0

=

OLD
<= div dir=3D"ltr" id=3D"m_5256923119158880231yui_3_16_0_ym19_1_1495466060991_= 9287" style=3D"font-family:"Helvetica Neue",Helvetica,Arial,"= ;Lucida Grande",sans-serif;font-size:16px">------

4.3 PDM as a Covert Channel

= =C2=A0 =C2=A0PDM provides a set of fields in the packet which could be used= to
=C2=A0 =C2=A0leak data. =C2=A0 But, there is no real reaso= n to suspect that PDM would
=C2=A0 =C2=A0be chosen rather than= another part of the payload or another
=C2=A0 =C2=A0Extension= Header.

=C2=A0 =C2=A0A firewall or another device co= uld sanity check the fields within the
=C2=A0 =C2=A0PDM but ra= ndomly assigned sequence numbers and delta times might be
=C2= =A0 =C2=A0expected to vary widely. =C2=A0 The biggest problem though is how= an
=C2=A0 =C2=A0attacker would get access to PDM in the first= place to leak data.=C2=A0
=C2=A0 =C2=A0The attacker would hav= e to either compromise the end host or have Man
=C2=A0 =C2=A0i= n the Middle (MitM).=C2=A0 It is possible that either one could change
=C2=A0 =C2=A0the fields. =C2=A0 But, then the other end host would= get sequence numbers
=C2=A0 =C2=A0and deltas that don't m= ake any sense. =C2=A0=C2=A0

=C2=A0 =C2=A0It is concei= vable that someone could compromise an end host and make
=C2= =A0 =C2=A0it start sending packets with PDM without the knowledge of the ho= st.=C2=A0
=C2=A0 =C2=A0But, again, the bigger problem is the c= ompromise of the end host. =C2=A0
=C2=A0 =C2=A0Once that is do= ne, the attacker probably has better ways to leak
=C2=A0 =C2= =A0data.

=C2=A0 =C2=A0Having said that, if a PDM awar= e middle box or an implementation
=C2=A0 =C2=A0detects some nu= mber of "nonsensical" sequence numbers it could take
=C2=A0 =C2=A0action to block (or alert on) this traffic.


New
------
=C2=A0
4.3 PDM as a Covert Channel
<= div dir=3D"ltr" id=3D"m_5256923119158880231yui_3_16_0_ym19_1_1495466060991_= 10834">
=C2=A0 =C2=A0PDM provides a set of fields in the packet whi= ch could be used to
=C2=A0 =C2=A0leak data. =C2=A0 But, there = is no real reason to suspect that PDM would
=C2=A0 =C2=A0be ch= osen rather than another part of the payload or another
=C2=A0= =C2=A0Extension Header.

=C2=A0 =C2=A0A firewall or a= nother device could sanity check the fields within the
=C2=A0 = =C2=A0PDM but randomly assigned sequence numbers and delta times might be
=C2=A0 =C2=A0expected to vary widely. =C2=A0 The biggest proble= m though is how an
=C2=A0 =C2=A0attacker would get access to P= DM in the first place to leak data.=C2=A0
=C2=A0 =C2=A0The att= acker would have to either compromise the end host or have Man
=C2=A0 =C2=A0in the Middle (MitM).=C2=A0 It is possible that either one co= uld change
=C2=A0 =C2=A0the fields. =C2=A0 But, then the other= end host would get sequence numbers
=C2=A0 =C2=A0and deltas t= hat don't make any sense. =C2=A0=C2=A0

=C2=A0 =C2= =A0It is conceivable that someone could compromise an end host and make
=C2=A0 =C2=A0it start sending packets with PDM without the knowle= dge of the host.=C2=A0
=C2=A0 =C2=A0But, again, the bigger pro= blem is the compromise of the end host. =C2=A0
=C2=A0 =C2=A0On= ce that is done, the attacker probably has better ways to leak
=C2=A0 =C2=A0data.

=C2=A0 =C2=A0Having said that, if= a PDM aware middle box or an implementation (destination
=C2= =A0 =C2=A0host) detects some number of "nonsensical" sequence num= bers or timing
=C2=A0 =C2=A0information, it could take action = to block, discard, or alert on this traffic.
=


>- It se= ems like you could use this technique for fine-grained
> =C2=A0timing of the cryptographic opera= tions traffic keys as well (cf. Lucky 13),
> =C2=A0not just= long-term keys as you say in S 4.4.

> Note that both o= f these attacks are not ameliorated by restricting
> to host and= ports because one assumes that the attacker controls
> the ne= twork per 3552

I can change the langu= age in section 4.4 as follows:

Old
----
=C2=A0 =C2=A0Depending on the nature of the= cryptographic protocol used, it may be
=C2=A0 =C2=A0possible = to leak the long term credentials of the device.=C2=A0 For
=C2= =A0 =C2=A0example, if an attacker is able to create an attack which causes = the
=C2=A0 =C2=A0enterprise to turn on PDM to diagnose the att= ack, then the attacker
=C2=A0 =C2=A0might use PDM during that = debugging time to launch a timing attack
=C2=A0 =C2=A0against = the long term keying material used by the cryptographic
=C2=A0= =C2=A0protocol.

New
= ----
=C2=A0 =C2=A0Depending on the nature of the crypt= ographic protocol used, it may be
=C2=A0 =C2=A0possible to lea= k the credentials of the device.=C2=A0 For
=C2=A0 =C2=A0exampl= e, if an attacker is able to create an attack which causes the
=C2=A0 =C2=A0enterprise to turn on PDM to diagnose the attack, then the at= tacker
=C2=A0 =C2=A0might use PDM during that debugging time t= o launch a timing attack
=C2=A0 =C2=A0against the keying mater= ial used by the cryptographic protocol.
=

= I'm not seeing this text in -12. Did I miss it?

Spencer
=C2=A0


=C2=A0
Thanks,

Nalini Elkins
CEO and Founder
Inside Prod= ucts, Inc.
www.inside= thestack.com
(831) 659-8360



--001a114c8a822ed0aa0552cd9bc1-- From nobody Sun Jun 25 16:54:49 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB476126D85 for ; Sun, 25 Jun 2017 16:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 DSsBArLennzy for ; Sun, 25 Jun 2017 16:54:41 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0DA124217 for ; Sun, 25 Jun 2017 16:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10886; q=dns/txt; s=iport; t=1498434881; x=1499644481; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6Et3Xz+rWse/aXHNdyYFIkwmPAJcShoZx9Xo9uHnROk=; b=k6mTJiHK79Yd7ixebUeFII1r0EEM9wFKStTimZpExcizw7nECmZmCzs9 e8ii/BN+FV9UakjuugIF7bDGB04CKsaWHnk8jwJGWt7bIvyNG7b3ruYVC /Dw5usn2B9vpnyjp8xBZ2IIaSfuCXcIEZ3dAQ9PYa/rRpHYlrITkkevG3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAABJTFBZ/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgystYoENB41+kV+VeoIRIQuCQoM2AoMIPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQMBARsdLQcXBAIBCBEEAQEWCQkHJwsUCQgCBAESCBOKERCzaItPAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWDJ4EbgjGBYYMkhSmFNQWQQoZGh2ECk1yCEoV?= =?us-ascii?q?IhQ6FM4kqi3YBHziBCnQVSYUNHIFmdogkgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.39,393,1493683200"; d="scan'208";a="445659272" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jun 2017 23:54:40 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v5PNsdQx028453 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 25 Jun 2017 23:54:39 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 25 Jun 2017 18:54:38 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Sun, 25 Jun 2017 18:54:38 -0500 From: "Frank Brockners (fbrockne)" To: "MORTON, ALFRED C (AL)" , "Brian Trammell (IETF)" , "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for draft-brockners-inband-oam-data Thread-Index: AQHS2R1C85PyjBoHHk2al2aC2B7oD6Irot6AgArFjEA= Date: Sun, 25 Jun 2017 23:54:38 +0000 Message-ID: <7ab8dc6eeb304082975be696a858b82a@XCH-ALN-008.cisco.com> References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25FDF7E7@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25FDF7E7@njmtexg5.research.att.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.214.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 23:54:48 -0000 Hi Al, thanks a lot for your comments. While integrating your comments into the do= c, a question on the roles of IOAM nodes arose. So far we have * IOAM encapsulating nodes (nodes which add IOAM container(s) ) * IOAM decapsulating nodes (nodes which removed IOAM container(s) ) * IOAM transit nodes (nodes which update/add IOAM data fields ) You suggest to add another role for "Devices within an IOAM domain can upda= te and/or add IOAM data-fields.". What isn't entirely clear to me is how th= ose devices would differ from IOAM transit nodes. Could you detail your thi= nking a bit more? Thanks, Frank -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Sonntag, 18. Juni 2017 15:17 To: Brian Trammell (IETF) ; ippm@ietf.org Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data Hi Brian and IPPMers, > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell > (IETF) ... >=20 > This message, therefore, starts a call for adoption on=20 > draft-brockners- inband-oam-data, to run until EOB CEST (UTC +2) Tuesday = 20 June 2017. > Please reply to ippm@ietf.org indicating: >=20 > (1) whether you support addition of the following milestone to the=20 > IPPM > charter: >=20 > date TBD: Submit an Experimental draft on inband OAM based measurement=20 > methodologies to the IESG [ACM] Given that most have concluded that in-situ OAM is categorized as Hybrid Ty= pe I (according to RFC 7799), the I would say that this statement in the ch= arter is *pretty close*: Additional methods will be defined for the composition and calibration o= f IPPM-defined metrics, as well as active, passive and hybrid measurement methods for these metrics. and I agree we can either adopt the draft now, or with a small tweak to the= charter text. The measurement methods mostly concern the data fields, and = do not define complete protocol solutions that will be subjected to more co= mplete review. Question: In the proposed milestone text, was "inband" used to have general= ity before "in-situ" is considered and adopted? I suggest s/inband/in-situ/ if the milestone and the draft are adopted toge= ther, to have clear limits. >=20 > (2) whether you support the adoption of=20 > draft-brockners-inband-oam-data- > 05 as the basis document for this milestone [ACM] Yes, I support this draft in particular. >=20 > (3) whether you commit to reviewing the document if adopted >=20 [ACM] Yes, I attach a review of the first three sections, below. regards, Al Internet-Draft In-situ OAM Data Fields May 2017 1. Introduction This document defines data fields for "in-situ" Operations, Administration, and Maintenance (OAM). In-situ OAM records OAM information within the packet while the packet traverses a particular network domain. The term "in-situ" refers to the fact that the OAM data is added to the data packets rather than is being sent within packets specifically dedicated to OAM. A discussion of the motivation and requirements for in-situ OAM can be found in [I-D.brockners-inband-oam-requirements]. In-situ OAM is to complement mechanisms such as Ping or Traceroute, or more recent active probing mechanisms as described in [ACM] Not clear to me why we = need two different definitions of "type". RFC7799 considers OAM measurements in its categorization.=20 It would be good to include the specific phrases of the definitions that pl= ace in-situ OAM in the Hybrid Type 1 Category, some of which were exchanged= in recent e-mail discussion of this draft. [I-D.lapukhov-dataplane-probe]. In terms of "active" or "passive" OAM, "in-situ" OAM can be considered a hybrid OAM type. While no extra packets are sent, in-situ OAM adds information to the packets therefore cannot be considered passive. In terms of the classification given in [RFC7799] in-situ OAM could be portrayed as "hybrid OAM, type 1".=20 [ACM] s/hybrid OAM, type 1/Hybrid Type 1/ I suggest to resist the urge to u= se double-quotes when indicating terms that have formal definitions elsewhe= re. The definitions are primarily for active/passive/hybrid *methods* of me= asurement (and for *metrics*, although I'm not sure we need to define metri= cs yet.) "In-situ" mechanisms do not require extra packets to be sent and hence don't change the packet traffic mix within the network. In-situ OAM mechanisms can be leveraged where mechanisms using e.g. ICMP do not apply or do not offer the desired results, such as proving that a certain traffic flow takes a pre- defined path, SLA verification for the live data traffic, detailed statistics on traffic distribution paths in networks that distribute traffic across multiple paths, or scenarios in which probe traffic is potentially handled differently from regular data traffic by the network devices. 2. Conventions [ACM] no comments this section 3. Scope, Applicability, and Assumptions In-situ OAM deployment assumes a set of constraints, requirements, and guiding principles which are described in this section. Scope: This document defines the data fields and associated data types for in-situ OAM. The in-situ OAM data field can be transported by a variety of transport protocols, including NSH, Segment Routing, [AC= M] s/transport/network/ ? In IETF, transport protocols are UDP and TCP (and= QUIC) Geneve, IPv6, or IPv4. Encapsulation details for these different transport protocols are outside the scope of this document. [ACM] s/Encapsulation/Specification/ Clearly, some of the protocols mentioned above perform encapsulation of oth= er protocol headers. This memo describes the additional fields to insert wh= en forming a new header, or optional fields to insert in an *existing* head= er (e.g., IPv4 and IPv6). I think the Scope should clearly indicate that th= ese two possibilities are included. Deployment domain (or scope) of in-situ OAM deployment: IOAM is a network domain focused feature, with "network domain" being a set of network devices or entities within a single administration. For example, a network domain can include an enterprise campus using physical connections between devices or an overlay network using virtual connections / tunnels for connectivity between said devices. A network domain is defined by its perimeter or edge. Designers of carrier protocols for IOAM must specify mechanisms to ensure that in- [A= CM] s/must/MUST/ =20 situ OAM data stays within an IOAM domain. In addition, the operator of such a domain is expected to put provisions in place to ensure that IOAM data does not leak beyond the edge of an IOAM domain, e.g. using for example packet filtering methods. The operator should consider potential operational impact of IOAM to mechanisms such as ECMP processing (e.g. load-balancing schemes based on packet length could be impacted by the increased packet size due to IOAM), path MTU (i.e. ensure that the MTU of all links within a domain is sufficiently large to support the increased packet size due to IOAM) and ICMP message handling (i.e. in case of a native IPv6 transport, IOAM support for ICMPv6 Echo Request/Reply could desired which would translate into ICMPv6 extensions to enable IOAM data fields to be copied from an Echo Request message to an Echo Reply message). [ACM] Comments on the control point definition below... In-situ OAM control points: IOAM data fields are added to or removed from the live user traffic by the devices which form the edge of a domain. Devices within an IOAM domain can update and/or add IOAM data-fields. Domain edge devices can be hosts or network devices. Traffic-sets that in-situ OAM is applied to: IOAM can be deployed on all or only on subsets of the live user traffic. It SHOULD be possible to enable in-situ OAM on a selected set of traffic (e.g., per interface, based on an access control list or flow specification defining a specific set of traffic, etc.) The selected set of traffic can also be all traffic. Encapsulation independence: Data formats for in-situ OAM SHOULD be defined in a transport-independent manner. In-situ OAM applies to a variety of encapsulating protocols. A definition of how IOAM data fields are carried by different transport protocols is outside the scope of this document. Layering: If several encapsulation protocols (e.g., in case of tunneling) are stacked on top of each other, in-situ OAM data-records could be present at every layer. The behavior follows the ships-in- the-night model. Combination with active OAM mechanisms: In-situ OAM should be usable for active network probing, enabling for example a customized version of traceroute. Decapsulating in-situ OAM nodes may have an ability to send the in-situ OAM information retrieved from the packet back to the source address of the packet or to the encapsulating node. [ACM] I'd like to see a slightly more complete naming scheme for the nodes = participating in IOAM methods. You already define *IOAM control points* abo= ve which seem to be the originators and terminators of the inserted IOAM fi= elds. These nodes are sometimes encapsulating and decapsulating nodes, but = not always (I think, see comment on IPv4+v6). There are also nodes which participate in the IOAM methods located internal= to the administrative/IOAM domain. I suggest that: "Devices within an IOAM domain can update and/or add IOAM data-fields." could have a different name that distinguishes their role. For a given path, these devices are simply members of the IOAM domain and p= erform a subset of the IOAM functions.=20 Although the role of these devices could change with a different path, ther= e could also be devices (or functions) that are always intended to be inter= nal to the IOAM domain, and need only a subset of IOAM capabilities.=20 I'll let the authors name these "members-only" nodes, but I think this role= is useful to distinguish. My guess is that there will be a linkage between= these roles and the three main types of in-situ data defined elsewhere. In-situ OAM implementation: The IOAM data-field definitions take the specifics of devices with hardware data-plane and software data-plane into account. -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Sun Jun 25 19:56:08 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9564B1200E5 for ; Sun, 25 Jun 2017 19:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zINwIzjZWNlv for ; Sun, 25 Jun 2017 19:56:04 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 0633F126D46 for ; Sun, 25 Jun 2017 19:56:03 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5Q2tZt8005328; Sun, 25 Jun 2017 22:56:00 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0083689.ppops.net-00191d01. with ESMTP id 2b9jw2jvkc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 25 Jun 2017 22:56:00 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v5Q2txdb079232; Sun, 25 Jun 2017 21:55:59 -0500 Received: from dalint02.pst.cso.att.com (dalint02.pst.cso.att.com [135.31.133.160]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v5Q2trOc079217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 21:55:54 -0500 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by dalint02.pst.cso.att.com (RSA Interceptor); Mon, 26 Jun 2017 02:09:30 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v5Q29ThL031245; Sun, 25 Jun 2017 21:09:30 -0500 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v5Q29OWh031084; Sun, 25 Jun 2017 21:09:24 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id 2A5ADE43AD; Sun, 25 Jun 2017 22:09:24 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Sun, 25 Jun 2017 22:09:23 -0400 From: "MORTON, ALFRED C (AL)" To: "Frank Brockners (fbrockne)" , "Brian Trammell (IETF)" , "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for draft-brockners-inband-oam-data Thread-Index: AQHS2R1AqruOCFv9rE2teRljJTp4IqIrRQhAgAtomgD//+D0oA== Date: Mon, 26 Jun 2017 02:09:23 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25FE61D0@njmtexg5.research.att.com> References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25FDF7E7@njmtexg5.research.att.com> <7ab8dc6eeb304082975be696a858b82a@XCH-ALN-008.cisco.com> In-Reply-To: <7ab8dc6eeb304082975be696a858b82a@XCH-ALN-008.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.204.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-26_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706260047 Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jun 2017 02:56:06 -0000 Hi Frank, I didn't see IOAM transit nodes as far as I read this time, and it seems to the class of node I was looking for. problem solved, Al > -----Original Message----- > From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] > Sent: Sunday, June 25, 2017 7:55 PM > To: MORTON, ALFRED C (AL); Brian Trammell (IETF); ippm@ietf.org > Subject: RE: [ippm] Adoption call for draft-brockners-inband-oam-data >=20 > Hi Al, >=20 > thanks a lot for your comments. While integrating your comments into the > doc, a question on the roles of IOAM nodes arose. So far we have >=20 > * IOAM encapsulating nodes (nodes which add IOAM container(s) ) > * IOAM decapsulating nodes (nodes which removed IOAM container(s) ) > * IOAM transit nodes (nodes which update/add IOAM data fields ) >=20 > You suggest to add another role for "Devices within an IOAM domain can > update and/or add IOAM data-fields.". What isn't entirely clear to me is > how those devices would differ from IOAM transit nodes. Could you detail > your thinking a bit more? >=20 > Thanks, Frank >=20 > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of MORTON, ALFRED C > (AL) > Sent: Sonntag, 18. Juni 2017 15:17 > To: Brian Trammell (IETF) ; ippm@ietf.org > Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data >=20 > Hi Brian and IPPMers, >=20 > > -----Original Message----- > > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell > > (IETF) > ... > > > > This message, therefore, starts a call for adoption on > > draft-brockners- inband-oam-data, to run until EOB CEST (UTC +2) > Tuesday 20 June 2017. > > Please reply to ippm@ietf.org indicating: > > > > (1) whether you support addition of the following milestone to the > > IPPM > > charter: > > > > date TBD: Submit an Experimental draft on inband OAM based measurement > > methodologies to the IESG > [ACM] > Given that most have concluded that in-situ OAM is categorized as Hybrid > Type I (according to RFC 7799), the I would say that this statement in > the charter is *pretty close*: >=20 > Additional methods will be defined for the composition and > calibration of > IPPM-defined metrics, as well as active, passive and hybrid > measurement > methods for these metrics. >=20 > and I agree we can either adopt the draft now, or with a small tweak to > the charter text. The measurement methods mostly concern the data > fields, and do not define complete protocol solutions that will be > subjected to more complete review. >=20 > Question: In the proposed milestone text, was "inband" used to have > generality before "in-situ" is considered and adopted? > I suggest s/inband/in-situ/ if the milestone and the draft are adopted > together, to have clear limits. >=20 > > > > (2) whether you support the adoption of > > draft-brockners-inband-oam-data- > > 05 as the basis document for this milestone > [ACM] > Yes, I support this draft in particular. >=20 > > > > (3) whether you commit to reviewing the document if adopted > > > [ACM] > Yes, I attach a review of the first three sections, below. >=20 > regards, > Al >=20 > Internet-Draft In-situ OAM Data Fields May 2017 >=20 >=20 > 1. Introduction >=20 > This document defines data fields for "in-situ" Operations, > Administration, and Maintenance (OAM). In-situ OAM records OAM > information within the packet while the packet traverses a particular > network domain. The term "in-situ" refers to the fact that the OAM > data is added to the data packets rather than is being sent within > packets specifically dedicated to OAM. A discussion of the > motivation and requirements for in-situ OAM can be found in > [I-D.brockners-inband-oam-requirements]. In-situ OAM is to > complement mechanisms such as Ping or Traceroute, or more recent > active probing mechanisms as described in [ACM] Not clear to me why > we need two different definitions of "type". > RFC7799 considers OAM measurements in its categorization. > It would be good to include the specific phrases of the definitions that > place in-situ OAM in the Hybrid Type 1 Category, some of which were > exchanged in recent e-mail discussion of this draft. >=20 > [I-D.lapukhov-dataplane-probe]. In terms of "active" or "passive" > OAM, "in-situ" OAM can be considered a hybrid OAM type. While no > extra packets are sent, in-situ OAM adds information to the packets > therefore cannot be considered passive. In terms of the > classification given in [RFC7799] in-situ OAM could be portrayed as > "hybrid OAM, type 1". > [ACM] s/hybrid OAM, type 1/Hybrid Type 1/ I suggest to resist the urge > to use double-quotes when indicating terms that have formal definitions > elsewhere. The definitions are primarily for active/passive/hybrid > *methods* of measurement (and for *metrics*, although I'm not sure we > need to define metrics yet.) > "In-situ" mechanisms do not require extra > packets to be sent and hence don't change the packet traffic mix > within the network. In-situ OAM mechanisms can be leveraged where > mechanisms using e.g. ICMP do not apply or do not offer the desired > results, such as proving that a certain traffic flow takes a pre- > defined path, SLA verification for the live data traffic, detailed > statistics on traffic distribution paths in networks that distribute > traffic across multiple paths, or scenarios in which probe traffic is > potentially handled differently from regular data traffic by the > network devices. >=20 > 2. Conventions >=20 > [ACM] no comments this section >=20 > 3. Scope, Applicability, and Assumptions >=20 > In-situ OAM deployment assumes a set of constraints, requirements, > and guiding principles which are described in this section. >=20 > Scope: This document defines the data fields and associated data > types for in-situ OAM. The in-situ OAM data field can be transported > by a variety of transport protocols, including NSH, Segment Routing, > [ACM] s/transport/network/ ? In IETF, transport protocols are UDP and > TCP (and QUIC) >=20 > Geneve, IPv6, or IPv4. Encapsulation details for these different > transport protocols are outside the scope of this document. > [ACM] s/Encapsulation/Specification/ > Clearly, some of the protocols mentioned above perform encapsulation of > other protocol headers. This memo describes the additional fields to > insert when forming a new header, or optional fields to insert in an > *existing* header (e.g., IPv4 and IPv6). I think the Scope should > clearly indicate that these two possibilities are included. >=20 > Deployment domain (or scope) of in-situ OAM deployment: IOAM is a > network domain focused feature, with "network domain" being a set of > network devices or entities within a single administration. For > example, a network domain can include an enterprise campus using > physical connections between devices or an overlay network using > virtual connections / tunnels for connectivity between said devices. > A network domain is defined by its perimeter or edge. Designers of > carrier protocols for IOAM must specify mechanisms to ensure that in- > [ACM] s/must/MUST/ > situ OAM data stays within an IOAM domain. In addition, the operator > of such a domain is expected to put provisions in place to ensure > that IOAM data does not leak beyond the edge of an IOAM domain, e.g. > using for example packet filtering methods. The operator should > consider potential operational impact of IOAM to mechanisms such as > ECMP processing (e.g. load-balancing schemes based on packet length > could be impacted by the increased packet size due to IOAM), path MTU > (i.e. ensure that the MTU of all links within a domain is > sufficiently large to support the increased packet size due to IOAM) > and ICMP message handling (i.e. in case of a native IPv6 transport, > IOAM support for ICMPv6 Echo Request/Reply could desired which would > translate into ICMPv6 extensions to enable IOAM data fields to be > copied from an Echo Request message to an Echo Reply message). >=20 > [ACM] Comments on the control point definition below... > In-situ OAM control points: IOAM data fields are added to or removed > from the live user traffic by the devices which form the edge of a > domain. Devices within an IOAM domain can update and/or add IOAM > data-fields. Domain edge devices can be hosts or network devices. >=20 > Traffic-sets that in-situ OAM is applied to: IOAM can be deployed on > all or only on subsets of the live user traffic. It SHOULD be > possible to enable in-situ OAM on a selected set of traffic (e.g., > per interface, based on an access control list or flow specification > defining a specific set of traffic, etc.) The selected set of > traffic can also be all traffic. >=20 > Encapsulation independence: Data formats for in-situ OAM SHOULD be > defined in a transport-independent manner. In-situ OAM applies to a > variety of encapsulating protocols. A definition of how IOAM data > fields are carried by different transport protocols is outside the > scope of this document. >=20 > Layering: If several encapsulation protocols (e.g., in case of > tunneling) are stacked on top of each other, in-situ OAM data-records > could be present at every layer. The behavior follows the ships-in- > the-night model. >=20 > Combination with active OAM mechanisms: In-situ OAM should be usable > for active network probing, enabling for example a customized version > of traceroute. Decapsulating in-situ OAM nodes may have an ability > to send the in-situ OAM information retrieved from the packet back to > the source address of the packet or to the encapsulating node. > [ACM] I'd like to see a slightly more complete naming scheme for the > nodes participating in IOAM methods. You already define *IOAM control > points* above which seem to be the originators and terminators of the > inserted IOAM fields. These nodes are sometimes encapsulating and > decapsulating nodes, but not always (I think, see comment on IPv4+v6). > There are also nodes which participate in the IOAM methods located > internal to the administrative/IOAM domain. I suggest that: > "Devices within an IOAM domain can update and/or add IOAM data-fields." > could have a different name that distinguishes their role. > For a given path, these devices are simply members of the IOAM domain > and perform a subset of the IOAM functions. > Although the role of these devices could change with a different path, > there could also be devices (or functions) that are always intended to > be internal to the IOAM domain, and need only a subset of IOAM > capabilities. > I'll let the authors name these "members-only" nodes, but I think this > role is useful to distinguish. My guess is that there will be a linkage > between these roles and the three main types of in-situ data defined > elsewhere. >=20 > In-situ OAM implementation: The IOAM data-field definitions take the > specifics of devices with hardware data-plane and software data-plane > into account. >=20 > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwIFAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3Dm9voi8xLya6TPBn3_IgFJ6xD= UD- > YWwoQjZVXMruwhKw&s=3DjRJum_v8Peo66n9djtVCTImXZTtDJ00vljvEc10ZHkk&e=3D From nobody Mon Jun 26 07:16:02 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BDC129C31; Mon, 26 Jun 2017 07:16:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149848656092.31761.14093022868269972850@ietfa.amsl.com> Date: Mon, 26 Jun 2017 07:16:00 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-alt-mark-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 14:16:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics of the IETF. Title : Alternate Marking method for passive and hybrid performance monitoring Authors : Giuseppe Fioccola Alessandro Capello Mauro Cociglio Luca Castaldelli Mach(Guoyi) Chen Lianshu Zheng Greg Mirsky Tal Mizrahi Filename : draft-ietf-ippm-alt-mark-05.txt Pages : 31 Date : 2017-06-26 Abstract: This document describes a method to perform packet loss, delay and jitter measurements on live traffic. This method is based on Alternate Marking (Coloring) technique. A report on the operational experiment done at Telecom Italia is explained in order to give an example and show the method applicability. This technique can be applied in various situations as detailed in this document and could be considered passive or hybrid depending on the application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-alt-mark-05 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-alt-mark-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 Mon Jun 26 07:26:42 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1402F129C2F; Mon, 26 Jun 2017 07:26:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xzoG04D-vquc; Mon, 26 Jun 2017 07:26:38 -0700 (PDT) Received: from mx04.telecomitalia.it (mx04.telecomitalia.it [217.169.121.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEC512EA76; Mon, 26 Jun 2017 07:26:36 -0700 (PDT) X-AuditID: d9a97918-735ff7000000aca3-a9-5951199bbf83 Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx04.telecomitalia.it () with SMTP id 7D.53.44195.B9911595; Mon, 26 Jun 2017 16:26:35 +0200 (CEST) From: Fioccola Giuseppe To: "ippm@ietf.org" , "ippm-chairs@ietf.org" CC: "draft-ietf-ippm-alt-mark@ietf.org" Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-alt-mark-05.txt Thread-Index: AQHS7obC2Wk8reGWEkmXcFDkLwAvSaI3MILg Date: Mon, 26 Jun 2017 14:26:34 +0000 Message-ID: <550fed16b300468cb6bb37b5d14068d2@TELMBXB02RM001.telecomitalia.local> References: <149848656092.31761.14093022868269972850@ietfa.amsl.com> In-Reply-To: <149848656092.31761.14093022868269972850@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.239] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsXCxfdHSne2ZGCkwdVF6hZtayczWqze0c1m 0fPgHbMDs8eSJT+ZAhijGhhtEvPy8ksSS1IVUlKLk22VXDKLk3MSM3NTixRCUnNSk/NzlRQy U2yVjJUUCnISk1NzU/NKbJUSCwpS81KU7LgUMIANUFlmnkJqXnJ+SmZeuq2SZ7C/roWFqaWu oZJdYGlqcUm+Qm5qcXFienpmvkJqwnrBjKkTn7MUrBCtONY9ha2BcbJAFyMnh4SAicTRS32M ILaQwFQmieNbwGw2ARuJg69OsIHYIgIhEsuvLmXtYuTgYBbwlvi2xAbEFBawk+j+4g9R4SDR fW4iK4RtJNE1YTJYJ4uAqsT5C0fZQWxegUCJeROWQm1ykehp3wRWzyngKrHu+1oWEJtRQFZi wu5FYDXMAuISL6afYIe4UkBiyZ7zzBC2qMTLx/9YIWwDia1L97FA2IoST5unQtkyEguPTGaF mKMncWPqFDYIW1ti2cLXzBD3CEqcnPmEZQKj2Cwk62YhaZmFpGUWkpYFjCyrGEVzKwxM9Eog kZdZkpiTmaiXWbKJEZgobq6slNjB2L3W+RCjAAejEg/vao7ASCHWxLLiytxDjBIczEoivMHc QCHelMTKqtSi/Pii0pzU4kOMPsAQm8gsJZqcD0xieSXxhiYWlobGFhZGhhZmpjiElcR5Sw4F RAoJpANTV3ZqakFqEcw4Jg5OqQZG0fSfP9Zfcdh60L2qxfz4iyN7AktOPBfryzxqes3rgsdT e3HtkrbC9IOW/lEFn9/yLrbdt6b4FcOW0Evxbievei9ZaqV5+qzeClUFi23vYrVtzQrjxK5V /IuZwL/wwqf3M4N5XydsS2lzyqk32jCDybW732l7Ny+Lmn+z/Ru2ZTxz5fJVEvKUWIozEg21 mIuKEwH1teYYQQMAAA== Archived-At: Subject: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jun 2017 14:26:41 -0000 Hi All, This new version of draft-ietf-ippm-alt-mark addresses comments received dur= ing WGLC phase. I have included all the comments and the most important changes are: - the title is now "Alternate Marking method for passive and hybrid performa= nce monitoring". - the addition of a paragraph in the introduction section about the RFC7799= definitions. In addition there are other minor changes and typos. Thanks to all the reviewers, Giuseppe -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di internet-drafts@ietf.or= g Inviato: luned=EC 26 giugno 2017 16:16 A: i-d-announce@ietf.org Cc: ippm@ietf.org Oggetto: [ippm] I-D Action: draft-ietf-ippm-alt-mark-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directori= es. This draft is a work item of the IP Performance Metrics of the IETF. Title : Alternate Marking method for passive and hybrid pe= rformance monitoring Authors : Giuseppe Fioccola Alessandro Capello Mauro Cociglio Luca Castaldelli Mach(Guoyi) Chen Lianshu Zheng Greg Mirsky Tal Mizrahi Filename : draft-ietf-ippm-alt-mark-05.txt Pages : 31 Date : 2017-06-26 Abstract: This document describes a method to perform packet loss, delay and jitter measurements on live traffic. This method is based on Alternate Marking (Coloring) technique. A report on the operational experiment done at Telecom Italia is explained in order to give an example and show the method applicability. This technique can be applied in various situations as detailed in this document and could be considered passive or hybrid depending on the application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-alt-mark-05 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-alt-mark-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/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. From nobody Mon Jun 26 10:02:09 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E2A129B7A; Mon, 26 Jun 2017 10:02:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149849652284.18472.5189755418267981271@ietfa.amsl.com> Date: Mon, 26 Jun 2017 10:02:02 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-6man-pdm-option-13.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:02:03 -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 of the IETF. Title : IPv6 Performance and Diagnostic Metrics (PDM) Destination Option Authors : Nalini Elkins Robert M. Hamilton Michael S. Ackermann Filename : draft-ietf-ippm-6man-pdm-option-13.txt Pages : 32 Date : 2017-06-26 Abstract: To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real-time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) destination options extension header. The field limits, calculations, and usage in measurement of PDM are included in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-13 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-6man-pdm-option-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-6man-pdm-option-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 26 10:04:44 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A9412EAC4 for ; Mon, 26 Jun 2017 10:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.409 X-Spam-Level: X-Spam-Status: No, score=0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 CodqNvb5Q4a1 for ; Mon, 26 Jun 2017 10:04:36 -0700 (PDT) Received: from sonic307-17.consmr.mail.gq1.yahoo.com (sonic307-17.consmr.mail.gq1.yahoo.com [98.137.64.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C45712EAE1 for ; Mon, 26 Jun 2017 10:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1498496673; bh=5E1adpPHGBCiKw0Af+Mp+WYEClhBeIMpw9vmb+b4tG8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=jr3uD0mcH7+3nNce4UcN2ZLOC8YSwJDFWQqIcz93nVXWgy63eGoKjn0CfOQlqwVxcDphqoj2biNuNteZsqauxHXGNyIRKRm2XEMIp5N1zxwxpsQ1pW7lAS5q9QuYEwsQZ9VWJ2LiFQQE382G1xMLdfikbVtV5Uod/iUm7Ay7B/kvUwk4tSxJVH7VFuMR0dFKw0nWXA1KQwun621vkX2Ygw0CluUDXKw80tEBfJQMziSQ5gIqNI8juDKphx2h3KAs3xS+DLv7CLwBtlBoRo0Xvd5IA70Il3HYMy0xksg90ACYI0YjznH8I5BgsREiCxgwPo+kByNJJt3bj/6NRZaloA== X-YMail-OSG: Dk_V7TsVM1keWORJveSkyBxXtbeGW45vMSlJP9kunVql87TeF4LrTejLHvjLoxi Pdg1lgsvwdr7tQdW28WqIYc2fYxfn9a_klaZriwYYflZIctUPoNn6swRtGhvpiJkM8qd4ftdldQV 7g28F_uER91vs8pxEYIH35EZj4mPSiiGSsbhw80cNs6RFq9qcc_muvKq2f8NQhty4ytAPkHlJleH FBWG35eEjiWylMzSS2cpOo2YIwN1i_70nLGbf8DxX7v1L25.7vgCDk0OggvelE4x05VgWMvM3JKd UBVeqLZl4m0saPh4Cl.Hwqsx.Sh09bTYhBPeSGT7lONPqI0xeThT9HIUdnnEpSSLiK6gdLN1koAf t0wrm6QewkZoEqZqGX59K.4C3UbWRdSro7c1rcXi0EJ5Kb9xnkqErdX7XJYWMGIgqFwQRD99Ge6s TtplKma78WfYX7iiBeol64mEIRnGNItYuuqmtp57zHRGIwp_dWe.LShLYW_M39gMdRiC6GTCMuEQ gdCgvXxN391jO8gfuIM3djcbIyuz3L.ieriijEjJqOTIJFBLEq2WdxMLCW3pLpdHYBTlS6.KH32K bDevqEC7BHVFlcMiMBzqbBPSy Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 26 Jun 2017 17:04:33 +0000 Date: Mon, 26 Jun 2017 17:04:26 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Spencer Dawkins at IETF Cc: Eric Rescorla , The IESG , "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , Al Morton , "ippm@ietf.org" Message-ID: <1596928761.2561478.1498496666106@mail.yahoo.com> In-Reply-To: References: <149195586781.15796.5030067129991289423.idtracker@ietfa.amsl.com> <1119101915.4268397.1495467658355@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.9948 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36 Archived-At: Subject: Re: [ippm] Eric Rescorla's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jun 2017 17:04:38 -0000 Spencer, Thank you for catching that. I had not received a reply from Eric, so I had not made the changes. I was waiting to hear if he had any objection to the suggestion. I have now posted a new draft incorporating the change. https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Spencer Dawkins at IETF To: Nalini J Elkins Cc: Eric Rescorla ; The IESG ; "draft-ietf-ippm-6man-pdm-option@ietf.org" ; Bill Cerveny ; "ippm-chairs@ietf.org" ; Al Morton ; "ippm@ietf.org" Sent: Sunday, June 25, 2017 12:11 PM Subject: Re: Eric Rescorla's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) Hi, Nalini, On Mon, May 22, 2017 at 10:40 AM, Nalini J Elkins wrote: > > >>Eric Rescorla has entered the following ballot position for draft-ietf-ippm-6man-pdm- option-09: No Objection > > >>Please refer to https://www.ietf.org/iesg/ statement/discuss-criteria. html > >>for more information about IESG DISCUSS and COMMENT positions. > > > > > >>The document, along with other ballot positions, can be found here: > >>https://datatracker.ietf.org/ doc/draft-ietf-ippm-6man-pdm- option/ > > > > > >>----------------------------- ------------------------------ ----------- > >>COMMENT: > >>----------------------------- ------------------------------ ----------- > > > >>I think the description of timing attacks could use a bit more work. > > > >>Specifically: > > > >>- I am assuming that you should discard rather than using as timestamp > >> sources packets which fail ESP. This shouldn't be an issue for > >> transport mode because you process ESP first, but in tunnel mode > >> you allow either order, so it's a potential issue. > > > > > >I believe some of this is addressed in section 4.3. I can add that the >destination host may also wish to look at this behavior and to >discard such packets. > > > > >OLD >------ > > >4.3 PDM as a Covert Channel > > > PDM provides a set of fields in the packet which could be used to > leak data. But, there is no real reason to suspect that PDM would > be chosen rather than another part of the payload or another > Extension Header. > > > A firewall or another device could sanity check the fields within the > PDM but randomly assigned sequence numbers and delta times might be > expected to vary widely. The biggest problem though is how an > attacker would get access to PDM in the first place to leak data. > The attacker would have to either compromise the end host or have Man > in the Middle (MitM). It is possible that either one could change > the fields. But, then the other end host would get sequence numbers > and deltas that don't make any sense. > > > It is conceivable that someone could compromise an end host and make > it start sending packets with PDM without the knowledge of the host. > But, again, the bigger problem is the compromise of the end host. > Once that is done, the attacker probably has better ways to leak > data. > > > Having said that, if a PDM aware middle box or an implementation > detects some number of "nonsensical" sequence numbers it could take > action to block (or alert on) this traffic. > > > > >New >------ > >4.3 PDM as a Covert Channel > > > PDM provides a set of fields in the packet which could be used to > leak data. But, there is no real reason to suspect that PDM would > be chosen rather than another part of the payload or another > Extension Header. > > > A firewall or another device could sanity check the fields within the > PDM but randomly assigned sequence numbers and delta times might be > expected to vary widely. The biggest problem though is how an > attacker would get access to PDM in the first place to leak data. > The attacker would have to either compromise the end host or have Man > in the Middle (MitM). It is possible that either one could change > the fields. But, then the other end host would get sequence numbers > and deltas that don't make any sense. > > > It is conceivable that someone could compromise an end host and make > it start sending packets with PDM without the knowledge of the host. > But, again, the bigger problem is the compromise of the end host. > Once that is done, the attacker probably has better ways to leak > data. > > > Having said that, if a PDM aware middle box or an implementation (destination > host) detects some number of "nonsensical" sequence numbers or timing > information, it could take action to block, discard, or alert on this traffic. > > > > > > >>- It seems like you could use this technique for fine-grained >> timing of the cryptographic operations traffic keys as well (cf. Lucky 13), >> not just long-term keys as you say in S 4.4. > > > >> Note that both of these attacks are not ameliorated by restricting > >> to host and ports because one assumes that the attacker controls > >> the network per 3552 > > >I can change the language in section 4.4 as follows: > > >Old >---- > Depending on the nature of the cryptographic protocol used, it may be > possible to leak the long term credentials of the device. For > example, if an attacker is able to create an attack which causes the > enterprise to turn on PDM to diagnose the attack, then the attacker > might use PDM during that debugging time to launch a timing attack > against the long term keying material used by the cryptographic > protocol. > > >New >---- > Depending on the nature of the cryptographic protocol used, it may be > possible to leak the credentials of the device. For > example, if an attacker is able to create an attack which causes the > enterprise to turn on PDM to diagnose the attack, then the attacker > might use PDM during that debugging time to launch a timing attack > against the keying material used by the cryptographic protocol. I'm not seeing this text in -12. Did I miss it? Spencer > > > > >Thanks, > >Nalini Elkins >CEO and Founder >Inside Products, Inc. >www.insidethestack.com >(831) 659-8360 > > > > From nobody Mon Jun 26 17:48:20 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE859126D85; Mon, 26 Jun 2017 17:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 6BmyF77mM81k; Mon, 26 Jun 2017 17:48:16 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788B9127180; Mon, 26 Jun 2017 17:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8514; q=dns/txt; s=iport; t=1498524496; x=1499734096; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CqIkUROpDJy2U4v7Mh190v1ZUaLIGOeKtGrBKjUrND0=; b=MKqXef3Dxjr7jEYbURM0aKFcKmvVh5uv1vAnLEOR4TBVoZ1vmo+jDtm5 WyH1kJFUMSZ5xcSlyncvUbhulI7K1tYdSeimOsX/a5QC3nG2fIsc1VRFN HBqK36fnSpL1afu5rEwW9LIN4B4SJNAulcYfKObr2WY89MAR8s9ghI6DF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQD1qVFZ/5NdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9pYoENB4NlihmiMoUrghEshXgCGoJTPxgBAgEBAQEBAQFrKIUZBiN?= =?us-ascii?q?WEAIBCD8DAgICMBQRAgQOBRuJLWQQsDaCJotcAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGAWDJ4NMggyCeYd9MIIxBZceh00ChzKMM4IKhUiKQZUgAR84gQp0FVsBhnx?= =?us-ascii?q?2iCmBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,398,1493683200"; d="scan'208,217";a="444414578" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 00:48:15 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v5R0mFSb007047 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Jun 2017 00:48:15 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 26 Jun 2017 20:48:14 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 26 Jun 2017 20:48:14 -0400 From: "Carlos Pignataro (cpignata)" To: Haoyu song CC: "ippm@ietf.org" , "draft-brockners-inband-oam-data.authors@ietf.org" Thread-Topic: draft on iOAM scalability improvement Thread-Index: AQHS7t8P1Hpx1HnPBUqLNMmDWqUYsw== Date: Tue, 27 Jun 2017 00:48:14 +0000 Message-ID: References: <78A2745BE9B57D4F9D27F86655EB87F925845299@SJCEML701-CHM.china.huawei.com> In-Reply-To: <78A2745BE9B57D4F9D27F86655EB87F925845299@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.131] Content-Type: multipart/alternative; boundary="_000_DED79A1E4FCF4C928C77A191FE512CEEciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] draft on iOAM scalability improvement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jun 2017 00:48:19 -0000 --_000_DED79A1E4FCF4C928C77A191FE512CEEciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGFveXUsDQoNClRoYW5rIHlvdSBmb3Igc2hhcmluZyBhIHZlcnkgd2VsbCB3cml0dGVuIGRyYWZ0 IOKAlCBib3RoIGluIGNvbnRlbnQgYW5kIGZvcm1hdCENCg0KVGhlIHdheSBpbiB3aGljaCBJIHNl ZSB0aGUgYW5hbHlzaXMgcHJlc2VudGVkLCBob3dldmVyLCBpcyBhIGJpdCBkaWZmZXJlbnQgdGhh biDigJxzY2FsYWJpbGl0eSBsaW1pdGF0aW9uc+KAnS4gSSBiZWxpZXZlIHRoZXNlIHByb3Bvc2Fs cyBhcmUgb3B0aW1pemF0aW9ucyBmb3Igc3BlY2lmaWMgc2NhbGluZyByZXF1aXJlbWVudHMgb3Ig Zm9yIHBhcnRpY3VsYXIgdXNlIGNhc2VzLiBJbiBmYWN0LCB0aGlzIGRyYWZ0IHNlZW1zIHRvIGRl c2NyaWJlIHRyYWRlb2ZmcyDigJQgYW5kIGhvdyB0byBwb25kZXIgdGhlIHdlaWdodHMgKHByZWNp c2lvbiwgcGFrIHNpemUsIHByb2Nlc3NpbmcpIGRlcGVuZHMgb24gdGhlIHVzZSBjYXNlIGFuZCB3 aGF0IHRvIG9wdGltaXplIChhcyBvcHBvc2VkIHRvIGEgcmlnaHQgdnMuIHdyb25nIGFuc3dlciku DQoNClNvLCB1bmRlciB3aGljaCBjb25kaXRpb25zIGRvIHlvdSBzZWUgdGhlc2UgYXMgdXNlZnVs Pw0KDQpUaGFua3MhDQoNCuKAlCBDYXJsb3MuDQoNCk9uIE1heSAyMiwgMjAxNywgYXQgMToyMiBQ TSwgSGFveXUgc29uZyA8aGFveXUuc29uZ0BodWF3ZWkuY29tPG1haWx0bzpoYW95dS5zb25nQGh1 YXdlaS5jb20+PiB3cm90ZToNCg0KRGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIGFuIGlP QU0gcmVsYXRlZCBkcmFmdCBhcyBmb2xsb3dzLiAgUGxlYXNlIGtpbmRseSBwcm92aWRlICBjb21t ZW50cyBhbmQgYWxzbyBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIHdoaWNo IHdpbGwgaGVscCB1cyBjb250aW51ZSB0byBpbXByb3ZlIHRoZSBkcmFmdC4gVGhhbmsgeW91IHZl cnkgbXVjaCENCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc29uZy1p cHBtLWlvYW0tc2NhbGFiaWxpdHkvDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgc2V2ZXJhbCBzY2FsYWJpbGl0eSBpc3N1ZXMgaW4gY3VycmVudCBpbi1zaXR1DQogICBP QU0gZG9jdW1lbnRzIGFuZCBwcm9wb3NlcyBjb3JyZXNwb25kaW5nIHNvbHV0aW9ucy4gIFNwZWNp ZmljYWxseSwgd2UNCiAgIGV4dGVuZCBpbi1zaXR1IE9BTSB0byBzdXBwb3J0IG1vcmUgc3RhbmRh cmQgdHJhY2luZyBkYXRhIHRoYW4gaXMNCiAgIGN1cnJlbnRseSBkZWZpbmVkIGFuZCBhZGQgbmV3 IGZlYXR1cmVzIHRvIGF2b2lkIGxpbWl0YXRpb25zIG9uIE1UVSwNCiAgIGJhbmR3aWR0aCwgZm9y d2FyZGluZyBwYXRoIGxlbmd0aCwgYW5kIG5vZGUgcHJvY2Vzc2luZyBjYXBhYmlsaXR5Lg0KDQoN Ckhhb3l1DQoNCg== --_000_DED79A1E4FCF4C928C77A191FE512CEEciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <76C23A8AEB658740975800F56433789C@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGFveXUsDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFuayB5b3UgZm9yIHNoYXJp bmcgYSB2ZXJ5IHdlbGwgd3JpdHRlbiBkcmFmdCDigJQgYm90aCBpbiBjb250ZW50IGFuZCBmb3Jt YXQhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5UaGUgd2F5IGluIHdoaWNoIEkgc2VlIHRoZSBhbmFseXNpcyBwcmVzZW50ZWQsIGhvd2V2 ZXIsIGlzIGEgYml0IGRpZmZlcmVudCB0aGFuIOKAnHNjYWxhYmlsaXR5IGxpbWl0YXRpb25z4oCd LiBJIGJlbGlldmUgdGhlc2UgcHJvcG9zYWxzIGFyZSBvcHRpbWl6YXRpb25zIGZvciBzcGVjaWZp YyBzY2FsaW5nIHJlcXVpcmVtZW50cyBvciBmb3IgcGFydGljdWxhciB1c2UgY2FzZXMuIEluIGZh Y3QsIHRoaXMgZHJhZnQgc2VlbXMgdG8NCiBkZXNjcmliZSB0cmFkZW9mZnMg4oCUIGFuZCBob3cg dG8gcG9uZGVyIHRoZSB3ZWlnaHRzIChwcmVjaXNpb24sIHBhayBzaXplLCBwcm9jZXNzaW5nKSBk ZXBlbmRzIG9uIHRoZSB1c2UgY2FzZSBhbmQgd2hhdCB0byBvcHRpbWl6ZSAoYXMgb3Bwb3NlZCB0 byBhIHJpZ2h0IHZzLiB3cm9uZyBhbnN3ZXIpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U28sIHVuZGVyIHdoaWNoIGNvbmRpdGlvbnMg ZG8geW91IHNlZSB0aGVzZSBhcyB1c2VmdWw/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MhPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2FybG9zLjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1heSAyMiwgMjAxNywgYXQgMToyMiBQTSwg SGFveXUgc29uZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhb3l1LnNvbmdAaHVhd2VpLmNvbSIgY2xh c3M9IiI+aGFveXUuc29uZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xh c3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQpEZWFyIGFsbCw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNw OzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQpXZSBoYXZlIHN1Ym1pdHRlZCBhbiBpT0FNIHJlbGF0ZWQgZHJhZnQgYXMgZm9sbG93cy4gJm5i c3A7UGxlYXNlIGtpbmRseSBwcm92aWRlICZuYnNwO2NvbW1lbnRzIGFuZCBhbHNvIGxldCB1cyBr bm93IGlmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMgd2hpY2ggd2lsbCBoZWxwIHVzIGNvbnRpbnVl IHRvIGltcHJvdmUgdGhlIGRyYWZ0LiBUaGFuayB5b3UgdmVyeSBtdWNoITxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N CjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXNvbmctaXBwbS1pb2FtLXNjYWxhYmlsaXR5LyIgc3R5bGU9ImNvbG9yOiBy Z2IoMTQ5LCA3OSwgMTE0KTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zb25nLWlwcG0taW9hbS1zY2Fs YWJpbGl0eS88L2E+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KQWJzdHJhY3Q6 PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHNldmVy YWwgc2NhbGFiaWxpdHkgaXNzdWVzIGluIGN1cnJlbnQgaW4tc2l0dTxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyBPQU0gZG9jdW1lbnRzIGFuZCBwcm9wb3NlcyBjb3JyZXNwb25kaW5nIHNvbHV0 aW9ucy4mbmJzcDsgU3BlY2lmaWNhbGx5LCB3ZTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyBl eHRlbmQgaW4tc2l0dSBPQU0gdG8gc3VwcG9ydCBtb3JlIHN0YW5kYXJkIHRyYWNpbmcgZGF0YSB0 aGFuIGlzPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7IGN1cnJlbnRseSBkZWZpbmVkIGFuZCBh ZGQgbmV3IGZlYXR1cmVzIHRvIGF2b2lkIGxpbWl0YXRpb25zIG9uIE1UVSw8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDsgYmFuZHdpZHRoLCBmb3J3YXJkaW5nIHBhdGggbGVuZ3RoLCBhbmQgbm9k ZSBwcm9jZXNzaW5nIGNhcGFiaWxpdHkuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJz cDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSGFveXU8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_DED79A1E4FCF4C928C77A191FE512CEEciscocom_-- From nobody Mon Jun 26 17:55:34 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6161C1273E2 for ; Mon, 26 Jun 2017 17:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 SSbculIdJSF6 for ; Mon, 26 Jun 2017 17:55:29 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7DE126C22 for ; Mon, 26 Jun 2017 17:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14328; q=dns/txt; s=iport; t=1498524929; x=1499734529; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jH6T7JfvkwqGdWTn/DTtyDK+nC9+L79DcKap5d/9aqA=; b=LfxhtgSqs0EZtOXCWWu6vsQT3yMZDPX8uLfc3UMnsN8dsv0dxF0tuxNP caR+ZOyu2vaMwSQfZytBWT3vDbvuzCN2cQoiHN8YgKK1Sz0KVv2lMIUwv lI0LdB0bPI0ZbYaat8J4WK7qchyOffSFoGcU8pO9cCtQR4dC0dPi9uetq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AABWrFFZ/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0Hg2WKGZFilXuCESELgkKDNgIaglM/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAgEBARsGETMHCwUHBAIBCA4HAwICERIDAgICJQsUARACBA4FG4oJC?= =?us-ascii?q?BCwPIImi1wBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELghyBG4IxgWErgnmEaj+?= =?us-ascii?q?CVDCCMQWQQoZch00Ck2ULgX+FSIpBiSqLdgEfOIEKdBVJEgGEehyBZnaIKYENA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.39,398,1493683200"; d="scan'208";a="260933710" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 00:55:28 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5R0tRrW018989 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Jun 2017 00:55:28 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 26 Jun 2017 20:55:27 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 26 Jun 2017 20:55:26 -0400 From: "Carlos Pignataro (cpignata)" To: Al Morton CC: "Brian Trammell (IETF)" , "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for draft-brockners-inband-oam-data Thread-Index: AQHS2R1AArCubVxfpEWBbTB3d8/A2KIrRQhAgA0L7AA= Date: Tue, 27 Jun 2017 00:55:26 +0000 Message-ID: References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25FDF7E7@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25FDF7E7@njmtexg5.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.131] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jun 2017 00:55:33 -0000 VGhhbmtzIEFsIGZvciB0aGUgcmV2aWV3IGFuZCBzdXBwb3J0IQ0KDQpJIGFncmVlIHdpdGggcy9p bmJhbmQvaW4tc2l0dS8NCg0KQWx0aG91Z2ggYXMgeW91IHBvaW50IG91dCwgdGhlIHNlbnRlbmNl IGluIHRoZSBleGlzdGluZyBjaGFydGVyIHNlZW1zIHRvIGNvdmVyIGZvciDigJxkZWZpbml0aW9u IG9mIGh5YnJpZCBtZXRob2Rz4oCdLg0KDQpUaGFua3MhDQoNCuKAlCBDYXJsb3MuDQoNCj4gT24g SnVuIDE4LCAyMDE3LCBhdCA2OjE3IFBNLCBNT1JUT04sIEFMRlJFRCBDIChBTCkgPGFjbW9ydG9u QGF0dC5jb20+IHdyb3RlOg0KPiANCj4gSGkgQnJpYW4gYW5kIElQUE1lcnMsDQo+IA0KPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGlwcG0gW21haWx0bzppcHBtLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBUcmFtbWVsbA0KPj4gKElFVEYpDQo+IC4u Lg0KPj4gDQo+PiBUaGlzIG1lc3NhZ2UsIHRoZXJlZm9yZSwgc3RhcnRzIGEgY2FsbCBmb3IgYWRv cHRpb24gb24gZHJhZnQtYnJvY2tuZXJzLQ0KPj4gaW5iYW5kLW9hbS1kYXRhLCB0byBydW4gdW50 aWwgRU9CIENFU1QgKFVUQyArMikgVHVlc2RheSAyMCBKdW5lIDIwMTcuDQo+PiBQbGVhc2UgcmVw bHkgdG8gaXBwbUBpZXRmLm9yZyBpbmRpY2F0aW5nOg0KPj4gDQo+PiAoMSkgd2hldGhlciB5b3Ug c3VwcG9ydCBhZGRpdGlvbiBvZiB0aGUgZm9sbG93aW5nIG1pbGVzdG9uZSB0byB0aGUgSVBQTQ0K Pj4gY2hhcnRlcjoNCj4+IA0KPj4gZGF0ZSBUQkQ6IFN1Ym1pdCBhbiBFeHBlcmltZW50YWwgZHJh ZnQgb24gaW5iYW5kIE9BTSBiYXNlZCBtZWFzdXJlbWVudA0KPj4gbWV0aG9kb2xvZ2llcyB0byB0 aGUgSUVTRw0KPiBbQUNNXSANCj4gR2l2ZW4gdGhhdCBtb3N0IGhhdmUgY29uY2x1ZGVkIHRoYXQg aW4tc2l0dSBPQU0gaXMgY2F0ZWdvcml6ZWQgYXMgDQo+IEh5YnJpZCBUeXBlIEkgKGFjY29yZGlu ZyB0byBSRkMgNzc5OSksIHRoZSBJIHdvdWxkIHNheSB0aGF0IHRoaXMNCj4gc3RhdGVtZW50IGlu IHRoZSBjaGFydGVyIGlzICpwcmV0dHkgY2xvc2UqOg0KPiANCj4gICBBZGRpdGlvbmFsIG1ldGhv ZHMgd2lsbCBiZSBkZWZpbmVkIGZvciB0aGUgY29tcG9zaXRpb24gYW5kIGNhbGlicmF0aW9uIG9m DQo+ICAgSVBQTS1kZWZpbmVkIG1ldHJpY3MsIGFzIHdlbGwgYXMgYWN0aXZlLCBwYXNzaXZlIGFu ZCBoeWJyaWQgbWVhc3VyZW1lbnQNCj4gICBtZXRob2RzIGZvciB0aGVzZSBtZXRyaWNzLg0KPiAN Cj4gYW5kIEkgYWdyZWUgd2UgY2FuIGVpdGhlciBhZG9wdCB0aGUgZHJhZnQgbm93LCBvciB3aXRo IGEgc21hbGwgdHdlYWsgdG8NCj4gdGhlIGNoYXJ0ZXIgdGV4dC4gVGhlIG1lYXN1cmVtZW50IG1l dGhvZHMgbW9zdGx5IGNvbmNlcm4gdGhlIGRhdGEgZmllbGRzLA0KPiBhbmQgZG8gbm90IGRlZmlu ZSBjb21wbGV0ZSBwcm90b2NvbCBzb2x1dGlvbnMgdGhhdCB3aWxsIGJlIHN1YmplY3RlZA0KPiB0 byBtb3JlIGNvbXBsZXRlIHJldmlldy4NCj4gDQo+IFF1ZXN0aW9uOiBJbiB0aGUgcHJvcG9zZWQg bWlsZXN0b25lIHRleHQsIHdhcyAiaW5iYW5kIiB1c2VkIHRvIGhhdmUgDQo+IGdlbmVyYWxpdHkg YmVmb3JlICJpbi1zaXR1IiBpcyBjb25zaWRlcmVkIGFuZCBhZG9wdGVkPw0KPiBJIHN1Z2dlc3Qg cy9pbmJhbmQvaW4tc2l0dS8gaWYgdGhlIG1pbGVzdG9uZSBhbmQgdGhlDQo+IGRyYWZ0IGFyZSBh ZG9wdGVkIHRvZ2V0aGVyLCB0byBoYXZlIGNsZWFyIGxpbWl0cy4NCj4gDQo+PiANCj4+ICgyKSB3 aGV0aGVyIHlvdSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBkcmFmdC1icm9ja25lcnMtaW5iYW5k LW9hbS1kYXRhLQ0KPj4gMDUgYXMgdGhlIGJhc2lzIGRvY3VtZW50IGZvciB0aGlzIG1pbGVzdG9u ZQ0KPiBbQUNNXSANCj4gWWVzLCBJIHN1cHBvcnQgdGhpcyBkcmFmdCBpbiBwYXJ0aWN1bGFyLg0K PiANCj4+IA0KPj4gKDMpIHdoZXRoZXIgeW91IGNvbW1pdCB0byByZXZpZXdpbmcgdGhlIGRvY3Vt ZW50IGlmIGFkb3B0ZWQNCj4+IA0KPiBbQUNNXSANCj4gWWVzLCBJIGF0dGFjaCBhIHJldmlldyBv ZiB0aGUgZmlyc3QgdGhyZWUgc2VjdGlvbnMsIGJlbG93Lg0KPiANCj4gcmVnYXJkcywNCj4gQWwN Cj4gDQo+IEludGVybmV0LURyYWZ0ICAgICAgICAgICBJbi1zaXR1IE9BTSBEYXRhIEZpZWxkcyAg ICAgICAgICAgICAgICBNYXkgMjAxNw0KPiANCj4gDQo+IDEuICBJbnRyb2R1Y3Rpb24NCj4gDQo+ ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGRhdGEgZmllbGRzIGZvciAiaW4tc2l0dSIgT3BlcmF0 aW9ucywNCj4gICBBZG1pbmlzdHJhdGlvbiwgYW5kIE1haW50ZW5hbmNlIChPQU0pLiAgSW4tc2l0 dSBPQU0gcmVjb3JkcyBPQU0NCj4gICBpbmZvcm1hdGlvbiB3aXRoaW4gdGhlIHBhY2tldCB3aGls ZSB0aGUgcGFja2V0IHRyYXZlcnNlcyBhIHBhcnRpY3VsYXINCj4gICBuZXR3b3JrIGRvbWFpbi4g IFRoZSB0ZXJtICJpbi1zaXR1IiByZWZlcnMgdG8gdGhlIGZhY3QgdGhhdCB0aGUgT0FNDQo+ICAg ZGF0YSBpcyBhZGRlZCB0byB0aGUgZGF0YSBwYWNrZXRzIHJhdGhlciB0aGFuIGlzIGJlaW5nIHNl bnQgd2l0aGluDQo+ICAgcGFja2V0cyBzcGVjaWZpY2FsbHkgZGVkaWNhdGVkIHRvIE9BTS4gIEEg ZGlzY3Vzc2lvbiBvZiB0aGUNCj4gICBtb3RpdmF0aW9uIGFuZCByZXF1aXJlbWVudHMgZm9yIGlu LXNpdHUgT0FNIGNhbiBiZSBmb3VuZCBpbg0KPiAgIFtJLUQuYnJvY2tuZXJzLWluYmFuZC1vYW0t cmVxdWlyZW1lbnRzXS4gIEluLXNpdHUgT0FNIGlzIHRvDQo+ICAgY29tcGxlbWVudCBtZWNoYW5p c21zIHN1Y2ggYXMgUGluZyBvciBUcmFjZXJvdXRlLCBvciBtb3JlIHJlY2VudA0KPiAgIGFjdGl2 ZSBwcm9iaW5nIG1lY2hhbmlzbXMgYXMgZGVzY3JpYmVkIGluDQo+IFtBQ01dICBOb3QgY2xlYXIg dG8gbWUgd2h5IHdlIG5lZWQgdHdvIGRpZmZlcmVudCBkZWZpbml0aW9ucyBvZiAidHlwZSIuDQo+ IFJGQzc3OTkgY29uc2lkZXJzIE9BTSBtZWFzdXJlbWVudHMgaW4gaXRzIGNhdGVnb3JpemF0aW9u LiANCj4gSXQgd291bGQgYmUgZ29vZCB0byBpbmNsdWRlIHRoZSBzcGVjaWZpYyBwaHJhc2VzIG9m IHRoZSBkZWZpbml0aW9ucw0KPiB0aGF0IHBsYWNlIGluLXNpdHUgT0FNIGluIHRoZSBIeWJyaWQg VHlwZSAxIENhdGVnb3J5LCBzb21lIG9mIHdoaWNoDQo+IHdlcmUgZXhjaGFuZ2VkIGluIHJlY2Vu dCBlLW1haWwgZGlzY3Vzc2lvbiBvZiB0aGlzIGRyYWZ0Lg0KPiANCj4gICBbSS1ELmxhcHVraG92 LWRhdGFwbGFuZS1wcm9iZV0uICBJbiB0ZXJtcyBvZiAiYWN0aXZlIiBvciAicGFzc2l2ZSINCj4g ICBPQU0sICJpbi1zaXR1IiBPQU0gY2FuIGJlIGNvbnNpZGVyZWQgYSBoeWJyaWQgT0FNIHR5cGUu ICBXaGlsZSBubw0KPiAgIGV4dHJhIHBhY2tldHMgYXJlIHNlbnQsIGluLXNpdHUgT0FNIGFkZHMg aW5mb3JtYXRpb24gdG8gdGhlIHBhY2tldHMNCj4gICB0aGVyZWZvcmUgY2Fubm90IGJlIGNvbnNp ZGVyZWQgcGFzc2l2ZS4gIEluIHRlcm1zIG9mIHRoZQ0KPiAgIGNsYXNzaWZpY2F0aW9uIGdpdmVu IGluIFtSRkM3Nzk5XSBpbi1zaXR1IE9BTSBjb3VsZCBiZSBwb3J0cmF5ZWQgYXMNCj4gICAiaHli cmlkIE9BTSwgdHlwZSAxIi4gDQo+IFtBQ01dIHMvaHlicmlkIE9BTSwgdHlwZSAxL0h5YnJpZCBU eXBlIDEvDQo+IEkgc3VnZ2VzdCB0byByZXNpc3QgdGhlIHVyZ2UgdG8gdXNlIGRvdWJsZS1xdW90 ZXMgd2hlbiBpbmRpY2F0aW5nIHRlcm1zDQo+IHRoYXQgaGF2ZSBmb3JtYWwgZGVmaW5pdGlvbnMg ZWxzZXdoZXJlLiBUaGUgZGVmaW5pdGlvbnMgYXJlIHByaW1hcmlseSBmb3IgDQo+IGFjdGl2ZS9w YXNzaXZlL2h5YnJpZCAqbWV0aG9kcyogb2YgbWVhc3VyZW1lbnQgKGFuZCBmb3IgKm1ldHJpY3Mq LCBhbHRob3VnaA0KPiBJJ20gbm90IHN1cmUgd2UgbmVlZCB0byBkZWZpbmUgbWV0cmljcyB5ZXQu KQ0KPiAgICJJbi1zaXR1IiBtZWNoYW5pc21zIGRvIG5vdCByZXF1aXJlIGV4dHJhDQo+ICAgcGFj a2V0cyB0byBiZSBzZW50IGFuZCBoZW5jZSBkb24ndCBjaGFuZ2UgdGhlIHBhY2tldCB0cmFmZmlj IG1peA0KPiAgIHdpdGhpbiB0aGUgbmV0d29yay4gIEluLXNpdHUgT0FNIG1lY2hhbmlzbXMgY2Fu IGJlIGxldmVyYWdlZCB3aGVyZQ0KPiAgIG1lY2hhbmlzbXMgdXNpbmcgZS5nLiAgSUNNUCBkbyBu b3QgYXBwbHkgb3IgZG8gbm90IG9mZmVyIHRoZSBkZXNpcmVkDQo+ICAgcmVzdWx0cywgc3VjaCBh cyBwcm92aW5nIHRoYXQgYSBjZXJ0YWluIHRyYWZmaWMgZmxvdyB0YWtlcyBhIHByZS0NCj4gICBk ZWZpbmVkIHBhdGgsIFNMQSB2ZXJpZmljYXRpb24gZm9yIHRoZSBsaXZlIGRhdGEgdHJhZmZpYywg ZGV0YWlsZWQNCj4gICBzdGF0aXN0aWNzIG9uIHRyYWZmaWMgZGlzdHJpYnV0aW9uIHBhdGhzIGlu IG5ldHdvcmtzIHRoYXQgZGlzdHJpYnV0ZQ0KPiAgIHRyYWZmaWMgYWNyb3NzIG11bHRpcGxlIHBh dGhzLCBvciBzY2VuYXJpb3MgaW4gd2hpY2ggcHJvYmUgdHJhZmZpYyBpcw0KPiAgIHBvdGVudGlh bGx5IGhhbmRsZWQgZGlmZmVyZW50bHkgZnJvbSByZWd1bGFyIGRhdGEgdHJhZmZpYyBieSB0aGUN Cj4gICBuZXR3b3JrIGRldmljZXMuDQo+IA0KPiAyLiAgQ29udmVudGlvbnMNCj4gDQo+IFtBQ01d IG5vIGNvbW1lbnRzIHRoaXMgc2VjdGlvbg0KPiANCj4gMy4gIFNjb3BlLCBBcHBsaWNhYmlsaXR5 LCBhbmQgQXNzdW1wdGlvbnMNCj4gDQo+ICAgSW4tc2l0dSBPQU0gZGVwbG95bWVudCBhc3N1bWVz IGEgc2V0IG9mIGNvbnN0cmFpbnRzLCByZXF1aXJlbWVudHMsDQo+ICAgYW5kIGd1aWRpbmcgcHJp bmNpcGxlcyB3aGljaCBhcmUgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbi4NCj4gDQo+ICAgU2Nv cGU6IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgZGF0YSBmaWVsZHMgYW5kIGFzc29jaWF0ZWQg ZGF0YQ0KPiAgIHR5cGVzIGZvciBpbi1zaXR1IE9BTS4gIFRoZSBpbi1zaXR1IE9BTSBkYXRhIGZp ZWxkIGNhbiBiZSB0cmFuc3BvcnRlZA0KPiAgIGJ5IGEgdmFyaWV0eSBvZiB0cmFuc3BvcnQgcHJv dG9jb2xzLCBpbmNsdWRpbmcgTlNILCBTZWdtZW50IFJvdXRpbmcsDQo+IFtBQ01dIHMvdHJhbnNw b3J0L25ldHdvcmsvDQo+ID8gSW4gSUVURiwgdHJhbnNwb3J0IHByb3RvY29scyBhcmUgVURQIGFu ZCBUQ1AgKGFuZCBRVUlDKQ0KPiANCj4gICBHZW5ldmUsIElQdjYsIG9yIElQdjQuICBFbmNhcHN1 bGF0aW9uIGRldGFpbHMgZm9yIHRoZXNlIGRpZmZlcmVudA0KPiAgIHRyYW5zcG9ydCBwcm90b2Nv bHMgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQo+IFtBQ01dIHMvRW5j YXBzdWxhdGlvbi9TcGVjaWZpY2F0aW9uLw0KPiBDbGVhcmx5LCBzb21lIG9mIHRoZSBwcm90b2Nv bHMgbWVudGlvbmVkIGFib3ZlIHBlcmZvcm0gZW5jYXBzdWxhdGlvbg0KPiBvZiBvdGhlciBwcm90 b2NvbCBoZWFkZXJzLiBUaGlzIG1lbW8gZGVzY3JpYmVzIHRoZSBhZGRpdGlvbmFsIGZpZWxkcw0K PiB0byBpbnNlcnQgd2hlbiBmb3JtaW5nIGEgbmV3IGhlYWRlciwgb3Igb3B0aW9uYWwgZmllbGRz IHRvIGluc2VydCBpbg0KPiBhbiAqZXhpc3RpbmcqIGhlYWRlciAoZS5nLiwgSVB2NCBhbmQgSVB2 NikuIEkgdGhpbmsgdGhlIFNjb3BlIA0KPiBzaG91bGQgY2xlYXJseSBpbmRpY2F0ZSB0aGF0IHRo ZXNlIHR3byBwb3NzaWJpbGl0aWVzIGFyZSBpbmNsdWRlZC4NCj4gDQo+ICAgRGVwbG95bWVudCBk b21haW4gKG9yIHNjb3BlKSBvZiBpbi1zaXR1IE9BTSBkZXBsb3ltZW50OiBJT0FNIGlzIGENCj4g ICBuZXR3b3JrIGRvbWFpbiBmb2N1c2VkIGZlYXR1cmUsIHdpdGggIm5ldHdvcmsgZG9tYWluIiBi ZWluZyBhIHNldCBvZg0KPiAgIG5ldHdvcmsgZGV2aWNlcyBvciBlbnRpdGllcyB3aXRoaW4gYSBz aW5nbGUgYWRtaW5pc3RyYXRpb24uICBGb3INCj4gICBleGFtcGxlLCBhIG5ldHdvcmsgZG9tYWlu IGNhbiBpbmNsdWRlIGFuIGVudGVycHJpc2UgY2FtcHVzIHVzaW5nDQo+ICAgcGh5c2ljYWwgY29u bmVjdGlvbnMgYmV0d2VlbiBkZXZpY2VzIG9yIGFuIG92ZXJsYXkgbmV0d29yayB1c2luZw0KPiAg IHZpcnR1YWwgY29ubmVjdGlvbnMgLyB0dW5uZWxzIGZvciBjb25uZWN0aXZpdHkgYmV0d2VlbiBz YWlkIGRldmljZXMuDQo+ICAgQSBuZXR3b3JrIGRvbWFpbiBpcyBkZWZpbmVkIGJ5IGl0cyBwZXJp bWV0ZXIgb3IgZWRnZS4gIERlc2lnbmVycyBvZg0KPiAgIGNhcnJpZXIgcHJvdG9jb2xzIGZvciBJ T0FNIG11c3Qgc3BlY2lmeSBtZWNoYW5pc21zIHRvIGVuc3VyZSB0aGF0IGluLQ0KPiBbQUNNXSBz L211c3QvTVVTVC8gIA0KPiAgIHNpdHUgT0FNIGRhdGEgc3RheXMgd2l0aGluIGFuIElPQU0gZG9t YWluLiAgSW4gYWRkaXRpb24sIHRoZSBvcGVyYXRvcg0KPiAgIG9mIHN1Y2ggYSBkb21haW4gaXMg ZXhwZWN0ZWQgdG8gcHV0IHByb3Zpc2lvbnMgaW4gcGxhY2UgdG8gZW5zdXJlDQo+ICAgdGhhdCBJ T0FNIGRhdGEgZG9lcyBub3QgbGVhayBiZXlvbmQgdGhlIGVkZ2Ugb2YgYW4gSU9BTSBkb21haW4s IGUuZy4NCj4gICB1c2luZyBmb3IgZXhhbXBsZSBwYWNrZXQgZmlsdGVyaW5nIG1ldGhvZHMuICBU aGUgb3BlcmF0b3Igc2hvdWxkDQo+ICAgY29uc2lkZXIgcG90ZW50aWFsIG9wZXJhdGlvbmFsIGlt cGFjdCBvZiBJT0FNIHRvIG1lY2hhbmlzbXMgc3VjaCBhcw0KPiAgIEVDTVAgcHJvY2Vzc2luZyAo ZS5nLiBsb2FkLWJhbGFuY2luZyBzY2hlbWVzIGJhc2VkIG9uIHBhY2tldCBsZW5ndGgNCj4gICBj b3VsZCBiZSBpbXBhY3RlZCBieSB0aGUgaW5jcmVhc2VkIHBhY2tldCBzaXplIGR1ZSB0byBJT0FN KSwgcGF0aCBNVFUNCj4gICAoaS5lLiBlbnN1cmUgdGhhdCB0aGUgTVRVIG9mIGFsbCBsaW5rcyB3 aXRoaW4gYSBkb21haW4gaXMNCj4gICBzdWZmaWNpZW50bHkgbGFyZ2UgdG8gc3VwcG9ydCB0aGUg aW5jcmVhc2VkIHBhY2tldCBzaXplIGR1ZSB0byBJT0FNKQ0KPiAgIGFuZCBJQ01QIG1lc3NhZ2Ug aGFuZGxpbmcgKGkuZS4gaW4gY2FzZSBvZiBhIG5hdGl2ZSBJUHY2IHRyYW5zcG9ydCwNCj4gICBJ T0FNIHN1cHBvcnQgZm9yIElDTVB2NiBFY2hvIFJlcXVlc3QvUmVwbHkgY291bGQgZGVzaXJlZCB3 aGljaCB3b3VsZA0KPiAgIHRyYW5zbGF0ZSBpbnRvIElDTVB2NiBleHRlbnNpb25zIHRvIGVuYWJs ZSBJT0FNIGRhdGEgZmllbGRzIHRvIGJlDQo+ICAgY29waWVkIGZyb20gYW4gRWNobyBSZXF1ZXN0 IG1lc3NhZ2UgdG8gYW4gRWNobyBSZXBseSBtZXNzYWdlKS4NCj4gDQo+IFtBQ01dIENvbW1lbnRz IG9uIHRoZSBjb250cm9sIHBvaW50IGRlZmluaXRpb24gYmVsb3cuLi4NCj4gICBJbi1zaXR1IE9B TSBjb250cm9sIHBvaW50czogSU9BTSBkYXRhIGZpZWxkcyBhcmUgYWRkZWQgdG8gb3IgcmVtb3Zl ZA0KPiAgIGZyb20gdGhlIGxpdmUgdXNlciB0cmFmZmljIGJ5IHRoZSBkZXZpY2VzIHdoaWNoIGZv cm0gdGhlIGVkZ2Ugb2YgYQ0KPiAgIGRvbWFpbi4gIERldmljZXMgd2l0aGluIGFuIElPQU0gZG9t YWluIGNhbiB1cGRhdGUgYW5kL29yIGFkZCBJT0FNDQo+ICAgZGF0YS1maWVsZHMuICBEb21haW4g ZWRnZSBkZXZpY2VzIGNhbiBiZSBob3N0cyBvciBuZXR3b3JrIGRldmljZXMuDQo+IA0KPiAgIFRy YWZmaWMtc2V0cyB0aGF0IGluLXNpdHUgT0FNIGlzIGFwcGxpZWQgdG86IElPQU0gY2FuIGJlIGRl cGxveWVkIG9uDQo+ICAgYWxsIG9yIG9ubHkgb24gc3Vic2V0cyBvZiB0aGUgbGl2ZSB1c2VyIHRy YWZmaWMuICBJdCBTSE9VTEQgYmUNCj4gICBwb3NzaWJsZSB0byBlbmFibGUgaW4tc2l0dSBPQU0g b24gYSBzZWxlY3RlZCBzZXQgb2YgdHJhZmZpYyAoZS5nLiwNCj4gICBwZXIgaW50ZXJmYWNlLCBi YXNlZCBvbiBhbiBhY2Nlc3MgY29udHJvbCBsaXN0IG9yIGZsb3cgc3BlY2lmaWNhdGlvbg0KPiAg IGRlZmluaW5nIGEgc3BlY2lmaWMgc2V0IG9mIHRyYWZmaWMsIGV0Yy4pICBUaGUgc2VsZWN0ZWQg c2V0IG9mDQo+ICAgdHJhZmZpYyBjYW4gYWxzbyBiZSBhbGwgdHJhZmZpYy4NCj4gDQo+ICAgRW5j YXBzdWxhdGlvbiBpbmRlcGVuZGVuY2U6IERhdGEgZm9ybWF0cyBmb3IgaW4tc2l0dSBPQU0gU0hP VUxEIGJlDQo+ICAgZGVmaW5lZCBpbiBhIHRyYW5zcG9ydC1pbmRlcGVuZGVudCBtYW5uZXIuICBJ bi1zaXR1IE9BTSBhcHBsaWVzIHRvIGENCj4gICB2YXJpZXR5IG9mIGVuY2Fwc3VsYXRpbmcgcHJv dG9jb2xzLiAgQSBkZWZpbml0aW9uIG9mIGhvdyBJT0FNIGRhdGENCj4gICBmaWVsZHMgYXJlIGNh cnJpZWQgYnkgZGlmZmVyZW50IHRyYW5zcG9ydCBwcm90b2NvbHMgaXMgb3V0c2lkZSB0aGUNCj4g ICBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gICBMYXllcmluZzogSWYgc2V2ZXJhbCBl bmNhcHN1bGF0aW9uIHByb3RvY29scyAoZS5nLiwgaW4gY2FzZSBvZg0KPiAgIHR1bm5lbGluZykg YXJlIHN0YWNrZWQgb24gdG9wIG9mIGVhY2ggb3RoZXIsIGluLXNpdHUgT0FNIGRhdGEtcmVjb3Jk cw0KPiAgIGNvdWxkIGJlIHByZXNlbnQgYXQgZXZlcnkgbGF5ZXIuICBUaGUgYmVoYXZpb3IgZm9s bG93cyB0aGUgc2hpcHMtaW4tDQo+ICAgdGhlLW5pZ2h0IG1vZGVsLg0KPiANCj4gICBDb21iaW5h dGlvbiB3aXRoIGFjdGl2ZSBPQU0gbWVjaGFuaXNtczogSW4tc2l0dSBPQU0gc2hvdWxkIGJlIHVz YWJsZQ0KPiAgIGZvciBhY3RpdmUgbmV0d29yayBwcm9iaW5nLCBlbmFibGluZyBmb3IgZXhhbXBs ZSBhIGN1c3RvbWl6ZWQgdmVyc2lvbg0KPiAgIG9mIHRyYWNlcm91dGUuICBEZWNhcHN1bGF0aW5n IGluLXNpdHUgT0FNIG5vZGVzIG1heSBoYXZlIGFuIGFiaWxpdHkNCj4gICB0byBzZW5kIHRoZSBp bi1zaXR1IE9BTSBpbmZvcm1hdGlvbiByZXRyaWV2ZWQgZnJvbSB0aGUgcGFja2V0IGJhY2sgdG8N Cj4gICB0aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBvciB0byB0aGUgZW5jYXBzdWxh dGluZyBub2RlLg0KPiBbQUNNXSBJJ2QgbGlrZSB0byBzZWUgYSBzbGlnaHRseSBtb3JlIGNvbXBs ZXRlIG5hbWluZyBzY2hlbWUgZm9yDQo+IHRoZSBub2RlcyBwYXJ0aWNpcGF0aW5nIGluIElPQU0g bWV0aG9kcy4gWW91IGFscmVhZHkgZGVmaW5lIA0KPiAqSU9BTSBjb250cm9sIHBvaW50cyogYWJv dmUgd2hpY2ggc2VlbSB0byBiZSB0aGUgb3JpZ2luYXRvcnMgYW5kIHRlcm1pbmF0b3JzDQo+IG9m IHRoZSBpbnNlcnRlZCBJT0FNIGZpZWxkcy4gVGhlc2Ugbm9kZXMgYXJlIHNvbWV0aW1lcyBlbmNh cHN1bGF0aW5nIGFuZCANCj4gZGVjYXBzdWxhdGluZyBub2RlcywgYnV0IG5vdCBhbHdheXMgKEkg dGhpbmssIHNlZSBjb21tZW50IG9uIElQdjQrdjYpLg0KPiBUaGVyZSBhcmUgYWxzbyBub2RlcyB3 aGljaCBwYXJ0aWNpcGF0ZSBpbiB0aGUgSU9BTSBtZXRob2RzIGxvY2F0ZWQNCj4gaW50ZXJuYWwg dG8gdGhlIGFkbWluaXN0cmF0aXZlL0lPQU0gZG9tYWluLiBJIHN1Z2dlc3QgdGhhdDoNCj4gIkRl dmljZXMgd2l0aGluIGFuIElPQU0gZG9tYWluIGNhbiB1cGRhdGUgYW5kL29yIGFkZCBJT0FNIGRh dGEtZmllbGRzLiINCj4gY291bGQgaGF2ZSBhIGRpZmZlcmVudCBuYW1lIHRoYXQgZGlzdGluZ3Vp c2hlcyB0aGVpciByb2xlLg0KPiBGb3IgYSBnaXZlbiBwYXRoLCB0aGVzZSBkZXZpY2VzIGFyZSBz aW1wbHkgbWVtYmVycyBvZiB0aGUgSU9BTSBkb21haW4NCj4gYW5kIHBlcmZvcm0gYSBzdWJzZXQg b2YgdGhlIElPQU0gZnVuY3Rpb25zLiANCj4gQWx0aG91Z2ggdGhlIHJvbGUgb2YgdGhlc2UgZGV2 aWNlcyBjb3VsZCBjaGFuZ2Ugd2l0aCBhIGRpZmZlcmVudCBwYXRoLA0KPiB0aGVyZSBjb3VsZCBh bHNvIGJlIGRldmljZXMgKG9yIGZ1bmN0aW9ucykgdGhhdCBhcmUgYWx3YXlzIGludGVuZGVkIHRv DQo+IGJlIGludGVybmFsIHRvIHRoZSBJT0FNIGRvbWFpbiwgYW5kIG5lZWQgb25seSBhIHN1YnNl dCBvZiANCj4gSU9BTSBjYXBhYmlsaXRpZXMuIA0KPiBJJ2xsIGxldCB0aGUgYXV0aG9ycyBuYW1l IHRoZXNlICJtZW1iZXJzLW9ubHkiIG5vZGVzLCBidXQgSSB0aGluaw0KPiB0aGlzIHJvbGUgaXMg dXNlZnVsIHRvIGRpc3Rpbmd1aXNoLiBNeSBndWVzcyBpcyB0aGF0IHRoZXJlIHdpbGwgYmUNCj4g YSBsaW5rYWdlIGJldHdlZW4gdGhlc2Ugcm9sZXMgYW5kIHRoZSB0aHJlZSBtYWluIHR5cGVzIG9m IGluLXNpdHUgZGF0YSANCj4gZGVmaW5lZCBlbHNld2hlcmUuDQo+IA0KPiAgIEluLXNpdHUgT0FN IGltcGxlbWVudGF0aW9uOiBUaGUgSU9BTSBkYXRhLWZpZWxkIGRlZmluaXRpb25zIHRha2UgdGhl DQo+ICAgc3BlY2lmaWNzIG9mIGRldmljZXMgd2l0aCBoYXJkd2FyZSBkYXRhLXBsYW5lIGFuZCBz b2Z0d2FyZSBkYXRhLXBsYW5lDQo+ICAgaW50byBhY2NvdW50Lg0KPiANCj4gLT0tPS09LT0tPS09 LT0tPS09LT0tDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBpcHBtIG1haWxpbmcgbGlzdA0KPiBpcHBtQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0KDQo= From nobody Mon Jun 26 18:48:58 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2918D1200FC; Mon, 26 Jun 2017 18:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 D0dhY_L7QPeC; Mon, 26 Jun 2017 18:48:55 -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 66D64127A91; Mon, 26 Jun 2017 18:48:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPW65506; Tue, 27 Jun 2017 01:48:52 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 27 Jun 2017 02:48:51 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML703-CHM.china.huawei.com ([169.254.5.136]) with mapi id 14.03.0301.000; Mon, 26 Jun 2017 18:48:49 -0700 From: Haoyu song To: "Carlos Pignataro (cpignata)" CC: "ippm@ietf.org" , "draft-brockners-inband-oam-data.authors@ietf.org" Thread-Topic: draft on iOAM scalability improvement Thread-Index: AdLTH0fsZe3MoWIbQhuBeTS1CfmKpQb+nM0AAAzlYUA= Date: Tue, 27 Jun 2017 01:48:48 +0000 Message-ID: <78A2745BE9B57D4F9D27F86655EB87F925956DE5@SJCEML702-CHM.china.huawei.com> References: <78A2745BE9B57D4F9D27F86655EB87F925845299@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.217.119] Content-Type: multipart/alternative; boundary="_000_78A2745BE9B57D4F9D27F86655EB87F925956DE5SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5951B984.0118, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a22c5299bc5b8ae6a65e2ddd07351373 Archived-At: Subject: Re: [ippm] draft on iOAM scalability improvement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jun 2017 01:48:57 -0000 --_000_78A2745BE9B57D4F9D27F86655EB87F925956DE5SJCEML702CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBjb21tZW50cyEgWW91IGFyZSByaWdodCB0 aGF0IGluIHRoZSBkcmFmdCB3ZSBpbnRlbmQgdG8gZGVzY3JpYmUgc29tZSBpbXBsZW1lbnRhdGlv biB0cmFkZW9mZnMgZGVwZW5kaW5nIG9uIHRoZSBkYXRhIHBsYW5lIGNhcGFiaWxpdHkgYW5kIHRo b3NlIHRyYWRlb2ZmcyBuZWVkIHRvIGFkZCBzb21lIGV4dHJhIGZsZXhpYmlsaXR5IHRvIHRoZSBj dXJyZW50IGlPQU0gaGVhZGVyIHNwZWNpZmljYXRpb24uDQpXaGlsZSBJT0FNIGRhdGEgaXMgdmVy eSB1c2VmdWwsIGl0cyBjb3N0IChiYW5kd2lkdGggY29uc3VtcHRpb24gYW5kIHByb2Nlc3Npbmcg cmVxdWlyZW1lbnRzKSBpcyBub3QgbmVnbGlnaWJsZS4gVGhlIHByb3RvY29sIHNob3VsZCBzdHJp dmUgdG8gYWxsb3cgZ3JhY2VmdWwgdHJhZGVvZmZzIGF0IHRoZSBiZWdpbm5pbmcuIEnigJltIHdv cmtpbmcgb24gYSByZXZpc2lvbiBvZiB0aGUgZHJhZnQgdG8gY2xhcmlmeSBpdC4gVGhhbmtzIQ0K DQpIYW95dQ0KDQoNCkZyb206IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNw aWduYXRhQGNpc2NvLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVuZSAyNiwgMjAxNyA1OjQ4IFBNDQpU bzogSGFveXUgc29uZyA8aGFveXUuc29uZ0BodWF3ZWkuY29tPg0KQ2M6IGlwcG1AaWV0Zi5vcmc7 IGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEuYXV0aG9yc0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IGRyYWZ0IG9uIGlPQU0gc2NhbGFiaWxpdHkgaW1wcm92ZW1lbnQNCg0KSGFveXUsDQoN ClRoYW5rIHlvdSBmb3Igc2hhcmluZyBhIHZlcnkgd2VsbCB3cml0dGVuIGRyYWZ0IOKAlCBib3Ro IGluIGNvbnRlbnQgYW5kIGZvcm1hdCENCg0KVGhlIHdheSBpbiB3aGljaCBJIHNlZSB0aGUgYW5h bHlzaXMgcHJlc2VudGVkLCBob3dldmVyLCBpcyBhIGJpdCBkaWZmZXJlbnQgdGhhbiDigJxzY2Fs YWJpbGl0eSBsaW1pdGF0aW9uc+KAnS4gSSBiZWxpZXZlIHRoZXNlIHByb3Bvc2FscyBhcmUgb3B0 aW1pemF0aW9ucyBmb3Igc3BlY2lmaWMgc2NhbGluZyByZXF1aXJlbWVudHMgb3IgZm9yIHBhcnRp Y3VsYXIgdXNlIGNhc2VzLiBJbiBmYWN0LCB0aGlzIGRyYWZ0IHNlZW1zIHRvIGRlc2NyaWJlIHRy YWRlb2ZmcyDigJQgYW5kIGhvdyB0byBwb25kZXIgdGhlIHdlaWdodHMgKHByZWNpc2lvbiwgcGFr IHNpemUsIHByb2Nlc3NpbmcpIGRlcGVuZHMgb24gdGhlIHVzZSBjYXNlIGFuZCB3aGF0IHRvIG9w dGltaXplIChhcyBvcHBvc2VkIHRvIGEgcmlnaHQgdnMuIHdyb25nIGFuc3dlcikuDQoNClNvLCB1 bmRlciB3aGljaCBjb25kaXRpb25zIGRvIHlvdSBzZWUgdGhlc2UgYXMgdXNlZnVsPw0KDQpUaGFu a3MhDQoNCuKAlCBDYXJsb3MuDQoNCk9uIE1heSAyMiwgMjAxNywgYXQgMToyMiBQTSwgSGFveXUg c29uZyA8aGFveXUuc29uZ0BodWF3ZWkuY29tPG1haWx0bzpoYW95dS5zb25nQGh1YXdlaS5jb20+ PiB3cm90ZToNCg0KRGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIGFuIGlPQU0gcmVsYXRl ZCBkcmFmdCBhcyBmb2xsb3dzLiAgUGxlYXNlIGtpbmRseSBwcm92aWRlICBjb21tZW50cyBhbmQg YWxzbyBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIHdoaWNoIHdpbGwgaGVs cCB1cyBjb250aW51ZSB0byBpbXByb3ZlIHRoZSBkcmFmdC4gVGhhbmsgeW91IHZlcnkgbXVjaCEN Cg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc29uZy1pcHBtLWlvYW0t c2NhbGFiaWxpdHkvDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgc2V2 ZXJhbCBzY2FsYWJpbGl0eSBpc3N1ZXMgaW4gY3VycmVudCBpbi1zaXR1DQogICBPQU0gZG9jdW1l bnRzIGFuZCBwcm9wb3NlcyBjb3JyZXNwb25kaW5nIHNvbHV0aW9ucy4gIFNwZWNpZmljYWxseSwg d2UNCiAgIGV4dGVuZCBpbi1zaXR1IE9BTSB0byBzdXBwb3J0IG1vcmUgc3RhbmRhcmQgdHJhY2lu ZyBkYXRhIHRoYW4gaXMNCiAgIGN1cnJlbnRseSBkZWZpbmVkIGFuZCBhZGQgbmV3IGZlYXR1cmVz IHRvIGF2b2lkIGxpbWl0YXRpb25zIG9uIE1UVSwNCiAgIGJhbmR3aWR0aCwgZm9yd2FyZGluZyBw YXRoIGxlbmd0aCwgYW5kIG5vZGUgcHJvY2Vzc2luZyBjYXBhYmlsaXR5Lg0KDQoNCkhhb3l1DQoN Cg== --_000_78A2745BE9B57D4F9D27F86655EB87F925956DE5SJCEML702CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I aSBDYXJsb3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFu ayB5b3UgZm9yIHRoZSBjb21tZW50cyEgWW91IGFyZSByaWdodCB0aGF0IGluIHRoZSBkcmFmdCB3 ZSBpbnRlbmQgdG8gZGVzY3JpYmUgc29tZSBpbXBsZW1lbnRhdGlvbiB0cmFkZW9mZnMgZGVwZW5k aW5nIG9uIHRoZSBkYXRhIHBsYW5lIGNhcGFiaWxpdHkgYW5kIHRob3NlDQogdHJhZGVvZmZzIG5l ZWQgdG8gYWRkIHNvbWUgZXh0cmEgZmxleGliaWxpdHkgdG8gdGhlIGN1cnJlbnQgaU9BTSBoZWFk ZXIgc3BlY2lmaWNhdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaGlsZSBJT0FNIGRhdGEgaXMg dmVyeSB1c2VmdWwsIGl0cyBjb3N0IChiYW5kd2lkdGggY29uc3VtcHRpb24gYW5kIHByb2Nlc3Np bmcgcmVxdWlyZW1lbnRzKSBpcyBub3QgbmVnbGlnaWJsZS4gVGhlIHByb3RvY29sIHNob3VsZCBz dHJpdmUgdG8gYWxsb3cgZ3JhY2VmdWwgdHJhZGVvZmZzDQogYXQgdGhlIGJlZ2lubmluZy4gSeKA mW0gd29ya2luZyBvbiBhIHJldmlzaW9uIG9mIHRoZSBkcmFmdCB0byBjbGFyaWZ5IGl0LiBUaGFu a3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IYW95dTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IENhcmxvcyBQaWduYXRhcm8gKGNw aWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBN b25kYXksIEp1bmUgMjYsIDIwMTcgNTo0OCBQTTxicj4NCjxiPlRvOjwvYj4gSGFveXUgc29uZyAm bHQ7aGFveXUuc29uZ0BodWF3ZWkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaXBwbUBpZXRmLm9y ZzsgZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS5hdXRob3JzQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBkcmFmdCBvbiBpT0FNIHNjYWxhYmlsaXR5IGltcHJvdmVtZW50 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFveXUsIDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZv ciBzaGFyaW5nIGEgdmVyeSB3ZWxsIHdyaXR0ZW4gZHJhZnQg4oCUIGJvdGggaW4gY29udGVudCBh bmQgZm9ybWF0ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgd2F5IGluIHdoaWNoIEkgc2VlIHRoZSBhbmFseXNpcyBwcmVzZW50ZWQsIGhv d2V2ZXIsIGlzIGEgYml0IGRpZmZlcmVudCB0aGFuIOKAnHNjYWxhYmlsaXR5IGxpbWl0YXRpb25z 4oCdLiBJIGJlbGlldmUgdGhlc2UgcHJvcG9zYWxzIGFyZSBvcHRpbWl6YXRpb25zIGZvciBzcGVj aWZpYyBzY2FsaW5nIHJlcXVpcmVtZW50cyBvciBmb3IgcGFydGljdWxhciB1c2UgY2FzZXMuIElu IGZhY3QsIHRoaXMgZHJhZnQgc2VlbXMNCiB0byBkZXNjcmliZSB0cmFkZW9mZnMg4oCUIGFuZCBo b3cgdG8gcG9uZGVyIHRoZSB3ZWlnaHRzIChwcmVjaXNpb24sIHBhayBzaXplLCBwcm9jZXNzaW5n KSBkZXBlbmRzIG9uIHRoZSB1c2UgY2FzZSBhbmQgd2hhdCB0byBvcHRpbWl6ZSAoYXMgb3Bwb3Nl ZCB0byBhIHJpZ2h0IHZzLiB3cm9uZyBhbnN3ZXIpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgdW5kZXIgd2hpY2ggY29uZGl0aW9ucyBk byB5b3Ugc2VlIHRoZXNlIGFzIHVzZWZ1bD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJQgQ2FybG9zLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWF5IDIyLCAyMDE3LCBh dCAxOjIyIFBNLCBIYW95dSBzb25nICZsdDs8YSBocmVmPSJtYWlsdG86aGFveXUuc29uZ0BodWF3 ZWkuY29tIj5oYW95dS5zb25nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGVhciBh bGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldlIGhhdmUg c3VibWl0dGVkIGFuIGlPQU0gcmVsYXRlZCBkcmFmdCBhcyBmb2xsb3dzLiAmbmJzcDtQbGVhc2Ug a2luZGx5IHByb3ZpZGUgJm5ic3A7Y29tbWVudHMgYW5kIGFsc28gbGV0IHVzIGtub3cgaWYgeW91 IGhhdmUgYW55IHF1ZXN0aW9ucyB3aGljaCB3aWxsIGhlbHAgdXMgY29udGludWUgdG8gaW1wcm92 ZSB0aGUNCiBkcmFmdC4gVGhhbmsgeW91IHZlcnkgbXVjaCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtc29uZy1pcHBtLWlvYW0tc2NhbGFiaWxpdHkvIj48c3BhbiBzdHlsZT0i Y29sb3I6Izk1NEY3MiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc29u Zy1pcHBtLWlvYW0tc2NhbGFiaWxpdHkvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QWJzdHJhY3Q6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDsmbmJzcDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgc2V2ZXJhbCBzY2FsYWJpbGl0eSBpc3N1 ZXMgaW4gY3VycmVudCBpbi1zaXR1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgT0FN IGRvY3VtZW50cyBhbmQgcHJvcG9zZXMgY29ycmVzcG9uZGluZyBzb2x1dGlvbnMuJm5ic3A7IFNw ZWNpZmljYWxseSwgd2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBleHRlbmQgaW4t c2l0dSBPQU0gdG8gc3VwcG9ydCBtb3JlIHN0YW5kYXJkIHRyYWNpbmcgZGF0YSB0aGFuIGlzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgY3VycmVudGx5IGRlZmluZWQgYW5kIGFkZCBu ZXcgZmVhdHVyZXMgdG8gYXZvaWQgbGltaXRhdGlvbnMgb24gTVRVLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7IGJhbmR3aWR0aCwgZm9yd2FyZGluZyBwYXRoIGxlbmd0aCwgYW5kIG5v ZGUgcHJvY2Vzc2luZyBjYXBhYmlsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhhb3l1PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_78A2745BE9B57D4F9D27F86655EB87F925956DE5SJCEML702CHMchi_-- From nobody Mon Jun 26 19:04:25 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CEC127A91; Mon, 26 Jun 2017 19:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 cpvLPKuzp7-J; Mon, 26 Jun 2017 19:04:21 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D49124B0A; Mon, 26 Jun 2017 19:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22434; q=dns/txt; s=iport; t=1498529060; x=1499738660; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9dvYCyiNpP/25IGLvAr858pwVfvm6TvVtm13ssd+Dyk=; b=j+1bdo7mKLQNT44w1NJ8mj/1q3XBL1DFJC7OUfJ3Hkcoez2W58o9dQSZ Nt/C8mT4+CSdEuqk7g5F16QvXX40HxEIk/eN0iwZxEgz9tD3rqKN5GMHz 5ybK420bK4w066vWRWhvDYcB4NtYeSdSoY85P7eqf/VgZ8pduXB/bKcrC U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AAD8vFFZ/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm88LWKBDQeDZYoZkWKVe4IRLIV4AhqCUz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQEDI1YQAgEIEQQBASgDAgICMBQJCAIEDgUbiS1kELANgiaLWwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgyeDTIFhK4J5hSCCXTCCMQWKRoxYh00ChzKMM4I?= =?us-ascii?q?KhUiKQZUgAR84gQp0FVsBhnx2iCmBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,398,1493683200"; d="scan'208,217";a="444434116" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 02:04:03 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v5R243Rn006746 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Jun 2017 02:04:03 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 26 Jun 2017 22:04:02 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 26 Jun 2017 22:04:02 -0400 From: "Carlos Pignataro (cpignata)" To: Haoyu song CC: "ippm@ietf.org" , "draft-brockners-inband-oam-data.authors@ietf.org" Thread-Topic: draft on iOAM scalability improvement Thread-Index: AQHS7t8P1Hpx1HnPBUqLNMmDWqUYs6I4NFkAgAAEPwA= Date: Tue, 27 Jun 2017 02:04:02 +0000 Message-ID: <00D7469D-DBC6-4D86-A393-060A4A877FED@cisco.com> References: <78A2745BE9B57D4F9D27F86655EB87F925845299@SJCEML701-CHM.china.huawei.com> <78A2745BE9B57D4F9D27F86655EB87F925956DE5@SJCEML702-CHM.china.huawei.com> In-Reply-To: <78A2745BE9B57D4F9D27F86655EB87F925956DE5@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.131] Content-Type: multipart/alternative; boundary="_000_00D7469DDBC64D86A393060A4A877FEDciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] draft on iOAM scalability improvement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jun 2017 02:04:23 -0000 --_000_00D7469DDBC64D86A393060A4A877FEDciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEhhb3l1LA0KDQpPbmUgb2YgbXkgcG9pbnRzIGlzIHRoYXQgdGhlIGRyYWZ0IHRhbGtzIGFi b3V0IGEgbnVtYmVyIG9mIOKAnGNvc3Rz4oCdIChpbmNsdWRpbmcgYWxzbyBzaXplKSBidXQgd2Ug Y2Fubm90IHNheSBob3cgbmVnbGlnaWJsZSBvciBub3QgdGhleSBhcmUgdW50aWwgd2UgdW5kZXJz dGFuZCB1bmRlciB3aGljaCB1c2UgY2FzZSB0aGV5IGFyZSBiZWluZyBjb25zaWRlcmVkLg0KDQpM b29rIGZvcndhcmQgdG8geW91ciBuZXh0IHZlcnNpb24sIGFuZCBpbiBwYXJ0aWN1bGFyIHVzZS1j YXNlIGFwcGxpY2FiaWxpdHkgdG8gdGhlIGRpZmZlcmVudCBjb3N0cyBhbmQgdHJhZGVvZmZzLiBU aGF0IHdheSwgdGhlIFdHIHdpbGwgYmUgYWJsZSB0byBzZWUgd2hlcmUgdG8gZm9jdXMgdGhlIG5l ZWQgZm9yIHByb3RvY29sIGZsZXhpYmlsaXR5IChhdCB0aGUgY29zdCBvZiBjb21wbGV4aXR5KS4N Cg0KVGhhbmtzIQ0KDQrigJQgQ2FybG9zLg0KDQpPbiBKdW4gMjYsIDIwMTcsIGF0IDk6NDggUE0s IEhhb3l1IHNvbmcgPGhhb3l1LnNvbmdAaHVhd2VpLmNvbTxtYWlsdG86aGFveXUuc29uZ0BodWF3 ZWkuY29tPj4gd3JvdGU6DQoNCkhpIENhcmxvcywNCg0KVGhhbmsgeW91IGZvciB0aGUgY29tbWVu dHMhIFlvdSBhcmUgcmlnaHQgdGhhdCBpbiB0aGUgZHJhZnQgd2UgaW50ZW5kIHRvIGRlc2NyaWJl IHNvbWUgaW1wbGVtZW50YXRpb24gdHJhZGVvZmZzIGRlcGVuZGluZyBvbiB0aGUgZGF0YSBwbGFu ZSBjYXBhYmlsaXR5IGFuZCB0aG9zZSB0cmFkZW9mZnMgbmVlZCB0byBhZGQgc29tZSBleHRyYSBm bGV4aWJpbGl0eSB0byB0aGUgY3VycmVudCBpT0FNIGhlYWRlciBzcGVjaWZpY2F0aW9uLg0KV2hp bGUgSU9BTSBkYXRhIGlzIHZlcnkgdXNlZnVsLCBpdHMgY29zdCAoYmFuZHdpZHRoIGNvbnN1bXB0 aW9uIGFuZCBwcm9jZXNzaW5nIHJlcXVpcmVtZW50cykgaXMgbm90IG5lZ2xpZ2libGUuIFRoZSBw cm90b2NvbCBzaG91bGQgc3RyaXZlIHRvIGFsbG93IGdyYWNlZnVsIHRyYWRlb2ZmcyBhdCB0aGUg YmVnaW5uaW5nLiBJ4oCZbSB3b3JraW5nIG9uIGEgcmV2aXNpb24gb2YgdGhlIGRyYWZ0IHRvIGNs YXJpZnkgaXQuIFRoYW5rcyENCg0KSGFveXUNCg0KDQpGcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChj cGlnbmF0YSkgW21haWx0bzpjcGlnbmF0YUBjaXNjby5jb21dDQpTZW50OiBNb25kYXksIEp1bmUg MjYsIDIwMTcgNTo0OCBQTQ0KVG86IEhhb3l1IHNvbmcgPGhhb3l1LnNvbmdAaHVhd2VpLmNvbTxt YWlsdG86aGFveXUuc29uZ0BodWF3ZWkuY29tPj4NCkNjOiBpcHBtQGlldGYub3JnPG1haWx0bzpp cHBtQGlldGYub3JnPjsgZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS5hdXRob3JzQGll dGYub3JnPG1haWx0bzpkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhLmF1dGhvcnNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogZHJhZnQgb24gaU9BTSBzY2FsYWJpbGl0eSBpbXByb3ZlbWVu dA0KDQpIYW95dSwNCg0KVGhhbmsgeW91IGZvciBzaGFyaW5nIGEgdmVyeSB3ZWxsIHdyaXR0ZW4g ZHJhZnQg4oCUIGJvdGggaW4gY29udGVudCBhbmQgZm9ybWF0IQ0KDQpUaGUgd2F5IGluIHdoaWNo IEkgc2VlIHRoZSBhbmFseXNpcyBwcmVzZW50ZWQsIGhvd2V2ZXIsIGlzIGEgYml0IGRpZmZlcmVu dCB0aGFuIOKAnHNjYWxhYmlsaXR5IGxpbWl0YXRpb25z4oCdLiBJIGJlbGlldmUgdGhlc2UgcHJv cG9zYWxzIGFyZSBvcHRpbWl6YXRpb25zIGZvciBzcGVjaWZpYyBzY2FsaW5nIHJlcXVpcmVtZW50 cyBvciBmb3IgcGFydGljdWxhciB1c2UgY2FzZXMuIEluIGZhY3QsIHRoaXMgZHJhZnQgc2VlbXMg dG8gZGVzY3JpYmUgdHJhZGVvZmZzIOKAlCBhbmQgaG93IHRvIHBvbmRlciB0aGUgd2VpZ2h0cyAo cHJlY2lzaW9uLCBwYWsgc2l6ZSwgcHJvY2Vzc2luZykgZGVwZW5kcyBvbiB0aGUgdXNlIGNhc2Ug YW5kIHdoYXQgdG8gb3B0aW1pemUgKGFzIG9wcG9zZWQgdG8gYSByaWdodCB2cy4gd3JvbmcgYW5z d2VyKS4NCg0KU28sIHVuZGVyIHdoaWNoIGNvbmRpdGlvbnMgZG8geW91IHNlZSB0aGVzZSBhcyB1 c2VmdWw/DQoNClRoYW5rcyENCg0K4oCUIENhcmxvcy4NCg0KT24gTWF5IDIyLCAyMDE3LCBhdCAx OjIyIFBNLCBIYW95dSBzb25nIDxoYW95dS5zb25nQGh1YXdlaS5jb208bWFpbHRvOmhhb3l1LnNv bmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpEZWFyIGFsbCwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQg YW4gaU9BTSByZWxhdGVkIGRyYWZ0IGFzIGZvbGxvd3MuICBQbGVhc2Uga2luZGx5IHByb3ZpZGUg IGNvbW1lbnRzIGFuZCBhbHNvIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMg d2hpY2ggd2lsbCBoZWxwIHVzIGNvbnRpbnVlIHRvIGltcHJvdmUgdGhlIGRyYWZ0LiBUaGFuayB5 b3UgdmVyeSBtdWNoIQ0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1z b25nLWlwcG0taW9hbS1zY2FsYWJpbGl0eS8NCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBzZXZlcmFsIHNjYWxhYmlsaXR5IGlzc3VlcyBpbiBjdXJyZW50IGluLXNpdHUN CiAgIE9BTSBkb2N1bWVudHMgYW5kIHByb3Bvc2VzIGNvcnJlc3BvbmRpbmcgc29sdXRpb25zLiAg U3BlY2lmaWNhbGx5LCB3ZQ0KICAgZXh0ZW5kIGluLXNpdHUgT0FNIHRvIHN1cHBvcnQgbW9yZSBz dGFuZGFyZCB0cmFjaW5nIGRhdGEgdGhhbiBpcw0KICAgY3VycmVudGx5IGRlZmluZWQgYW5kIGFk ZCBuZXcgZmVhdHVyZXMgdG8gYXZvaWQgbGltaXRhdGlvbnMgb24gTVRVLA0KICAgYmFuZHdpZHRo LCBmb3J3YXJkaW5nIHBhdGggbGVuZ3RoLCBhbmQgbm9kZSBwcm9jZXNzaW5nIGNhcGFiaWxpdHku DQoNCg0KSGFveXUNCg0K --_000_00D7469DDBC64D86A393060A4A877FEDciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1265ADF8DCF67E4390C6DB476460FF9D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksJm5ic3A7SGFveXUsDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5PbmUgb2YgbXkg cG9pbnRzIGlzIHRoYXQgdGhlIGRyYWZ0IHRhbGtzIGFib3V0IGEgbnVtYmVyIG9mIOKAnGNvc3Rz 4oCdIChpbmNsdWRpbmcgYWxzbyBzaXplKSBidXQgd2UgY2Fubm90IHNheSBob3cgbmVnbGlnaWJs ZSBvciBub3QgdGhleSBhcmUgdW50aWwgd2UgdW5kZXJzdGFuZCB1bmRlciB3aGljaCB1c2UgY2Fz ZSB0aGV5IGFyZSBiZWluZyBjb25zaWRlcmVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TG9vayBmb3J3YXJkIHRvIHlvdXIgbmV4dCB2 ZXJzaW9uLCBhbmQgaW4gcGFydGljdWxhciB1c2UtY2FzZSBhcHBsaWNhYmlsaXR5IHRvIHRoZSBk aWZmZXJlbnQgY29zdHMgYW5kIHRyYWRlb2Zmcy4gVGhhdCB3YXksIHRoZSBXRyB3aWxsIGJlIGFi bGUgdG8gc2VlIHdoZXJlIHRvIGZvY3VzIHRoZSBuZWVkIGZvciBwcm90b2NvbCBmbGV4aWJpbGl0 eSAoYXQgdGhlIGNvc3Qgb2YgY29tcGxleGl0eSkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MhPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2FybG9zLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEp1biAyNiwgMjAxNywgYXQgOTo0OCBQ TSwgSGFveXUgc29uZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhb3l1LnNvbmdAaHVhd2VpLmNvbSIg Y2xhc3M9IiI+aGFveXUuc29uZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs YXNzPSIiPkhpIENhcmxvcyw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5UaGFuayB5b3Ug Zm9yIHRoZSBjb21tZW50cyEgWW91IGFyZSByaWdodCB0aGF0IGluIHRoZSBkcmFmdCB3ZSBpbnRl bmQgdG8gZGVzY3JpYmUgc29tZSBpbXBsZW1lbnRhdGlvbiB0cmFkZW9mZnMgZGVwZW5kaW5nIG9u IHRoZSBkYXRhIHBsYW5lIGNhcGFiaWxpdHkgYW5kIHRob3NlDQogdHJhZGVvZmZzIG5lZWQgdG8g YWRkIHNvbWUgZXh0cmEgZmxleGliaWxpdHkgdG8gdGhlIGN1cnJlbnQgaU9BTSBoZWFkZXIgc3Bl Y2lmaWNhdGlvbi48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5XaGlsZSBJT0FNIGRhdGEgaXMgdmVyeSB1c2VmdWwsIGl0 cyBjb3N0IChiYW5kd2lkdGggY29uc3VtcHRpb24gYW5kIHByb2Nlc3NpbmcgcmVxdWlyZW1lbnRz KSBpcyBub3QgbmVnbGlnaWJsZS4gVGhlIHByb3RvY29sIHNob3VsZCBzdHJpdmUgdG8gYWxsb3cg Z3JhY2VmdWwgdHJhZGVvZmZzDQogYXQgdGhlIGJlZ2lubmluZy4gSeKAmW0gd29ya2luZyBvbiBh IHJldmlzaW9uIG9mIHRoZSBkcmFmdCB0byBjbGFyaWZ5IGl0LiBUaGFua3MhPG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyIgY2xhc3M9IiI+SGFveXU8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5 bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBib3JkZXItdG9wLWNv bG9yOiByZ2IoMjI1LCAyMjUsIDIyNSk7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyIgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Q2FybG9zIFBp Z25hdGFybyAoY3BpZ25hdGEpIFs8YSBocmVmPSJtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tIiBj bGFzcz0iIj5tYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tPC9hPl08c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+ U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pk1vbmRheSwgSnVuZSAyNiwgMjAxNyA1OjQ4IFBNPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+ VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5I YW95dSBzb25nICZsdDs8YSBocmVmPSJtYWlsdG86aGFveXUuc29uZ0BodWF3ZWkuY29tIiBjbGFz cz0iIj5oYW95dS5zb25nQGh1YXdlaS5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNz PSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIGNsYXNzPSIiPmlwcG1AaWV0Zi5vcmc8 L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEuYXV0 aG9yc0BpZXRmLm9yZyIgY2xhc3M9IiI+ZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS5h dXRob3JzQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9i PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogZHJh ZnQgb24gaU9BTSBzY2FsYWJpbGl0eSBpbXByb3ZlbWVudDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkhhb3l1LDxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NClRoYW5rIHlvdSBmb3Igc2hhcmluZyBhIHZlcnkgd2VsbCB3cml0dGVu IGRyYWZ0IOKAlCBib3RoIGluIGNvbnRlbnQgYW5kIGZvcm1hdCE8bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KVGhlIHdheSBpbiB3aGljaCBJIHNlZSB0aGUgYW5hbHlzaXMgcHJl c2VudGVkLCBob3dldmVyLCBpcyBhIGJpdCBkaWZmZXJlbnQgdGhhbiDigJxzY2FsYWJpbGl0eSBs aW1pdGF0aW9uc+KAnS4gSSBiZWxpZXZlIHRoZXNlIHByb3Bvc2FscyBhcmUgb3B0aW1pemF0aW9u cyBmb3Igc3BlY2lmaWMgc2NhbGluZyByZXF1aXJlbWVudHMgb3IgZm9yIHBhcnRpY3VsYXIgdXNl IGNhc2VzLiBJbiBmYWN0LCB0aGlzIGRyYWZ0IHNlZW1zIHRvIGRlc2NyaWJlIHRyYWRlb2Zmcw0K IOKAlCBhbmQgaG93IHRvIHBvbmRlciB0aGUgd2VpZ2h0cyAocHJlY2lzaW9uLCBwYWsgc2l6ZSwg cHJvY2Vzc2luZykgZGVwZW5kcyBvbiB0aGUgdXNlIGNhc2UgYW5kIHdoYXQgdG8gb3B0aW1pemUg KGFzIG9wcG9zZWQgdG8gYSByaWdodCB2cy4gd3JvbmcgYW5zd2VyKS48bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KU28sIHVuZGVyIHdoaWNoIGNvbmRpdGlvbnMgZG8geW91IHNl ZSB0aGVzZSBhcyB1c2VmdWw/PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClRo YW5rcyE8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K4oCUIENhcmxvcy48bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIE1h eSAyMiwgMjAxNywgYXQgMToyMiBQTSwgSGFveXUgc29uZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhh b3l1LnNvbmdAaHVhd2VpLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aGFveXUuc29uZ0BodWF3ZWkuY29tPC9hPiZndDsgd3Jv dGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkRlYXIgYWxs LDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5XZSBoYXZlIHN1Ym1pdHRlZCBhbiBpT0FNIHJl bGF0ZWQgZHJhZnQgYXMgZm9sbG93cy4gJm5ic3A7UGxlYXNlIGtpbmRseSBwcm92aWRlICZuYnNw O2NvbW1lbnRzIGFuZCBhbHNvIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMg d2hpY2ggd2lsbCBoZWxwIHVzIGNvbnRpbnVlIHRvIGltcHJvdmUgdGhlIGRyYWZ0LiBUaGFuaw0K IHlvdSB2ZXJ5IG11Y2ghPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNvbmctaXBwbS1pb2FtLXNjYWxhYmls aXR5LyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIg Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMTQ5LCA3OSwgMTE0KTsiIGNsYXNzPSIi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNvbmctaXBwbS1pb2FtLXNj YWxhYmlsaXR5Lzwvc3Bhbj48L2E+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpw Pjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkFic3RyYWN0 OjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHNldmVyYWwg c2NhbGFiaWxpdHkgaXNzdWVzIGluIGN1cnJlbnQgaW4tc2l0dTxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7Jm5i c3A7IE9BTSBkb2N1bWVudHMgYW5kIHByb3Bvc2VzIGNvcnJlc3BvbmRpbmcgc29sdXRpb25zLiZu YnNwOyBTcGVjaWZpY2FsbHksIHdlPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgZXh0ZW5kIGluLXNp dHUgT0FNIHRvIHN1cHBvcnQgbW9yZSBzdGFuZGFyZCB0cmFjaW5nIGRhdGEgdGhhbiBpczxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+Jm5ic3A7Jm5ic3A7IGN1cnJlbnRseSBkZWZpbmVkIGFuZCBhZGQgbmV3IGZlYXR1cmVz IHRvIGF2b2lkIGxpbWl0YXRpb25zIG9uIE1UVSw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBiYW5k d2lkdGgsIGZvcndhcmRpbmcgcGF0aCBsZW5ndGgsIGFuZCBub2RlIHByb2Nlc3NpbmcgY2FwYWJp bGl0eS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PG86cCBjbGFzcz0iIj48L286 cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5IYW95dTwv c3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_00D7469DDBC64D86A393060A4A877FEDciscocom_-- From nobody Tue Jun 27 07:31:27 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B4C1274D0 for ; Tue, 27 Jun 2017 07:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7vefMpMw6Qw0 for ; Tue, 27 Jun 2017 07:31:24 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015301241FC for ; Tue, 27 Jun 2017 07:31:24 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id h22so18270622lfk.3 for ; Tue, 27 Jun 2017 07:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=MRWpi3YInGpGSI7vauTpR3Y8WeaoZwUERDP87X/NaGk=; b=FRz9n/5H2y2P6jY7xZcZD2paTt/A8z5Q8RKQGe3bgcODjquF3WWvMzHjqGZx2fgmEE +1d9h2zrkZ9CbroklxTnKjBPBp0e7kP40QjTw3liRA1Y/tHWw6IfycR8McuGblxIcgWm CbdrFxJ6yB8MKQKDgpY/P4pHYmILOAGkRBKoETi91XysWF2fks8aAaetkOYiuULmC++R RFvWeiBKUbE6tGa5TXQyLQN1xbdMjUReRMy44Hoe17WM7GmyKSG3iHG6JtYNhXfwqd5W ZjoS5UNwE0bSs+NBDVhAVnIcE9iphrqZKrdk0T8N60x0xfD/qIFAPEY68imUG8xKyh6V YjyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=MRWpi3YInGpGSI7vauTpR3Y8WeaoZwUERDP87X/NaGk=; b=BAVUQjIVu5/t62Zbdv8jDEWKgUsBYKkeUO4rf3E/3wfPJsJSElkAu8VCkv8Ay2GQgM WVHurz4ybM0ZAwYMK63JfqtsVvJIGebKeuIN3SxfycVn7Tgj1QsKRRVzVe2APJYgmDJG sruVF8JpYH6NcCCh02zbXwgu1kremR+RN+AJtf4LVxIjrKiFlvIC8S4mUaZpMVeZGDsW 9QguCVHABBSZoWeByiHcuELlRLryToZq+71HkNdQ15tiQb1c2nMfrfHC7PU6oxwGgpMw fCw701+l5Oh9jqyabTXEWZsTABv+AMVTEkzqoIIx9OSNd8YLt2W9ypiKtww7+9imA/QE vHPw== X-Gm-Message-State: AKS2vOx3TenVPWqY42tILqNvWUz5YALl1oYCIOqAhV7C+nD4PixPokOC o/aXmKsnKcECp2H9cy+tuB1qlHLX2A== X-Received: by 10.25.196.84 with SMTP id u81mr1125450lff.30.1498573881808; Tue, 27 Jun 2017 07:31:21 -0700 (PDT) MIME-Version: 1.0 From: Praveen Ananthasankaran Date: Tue, 27 Jun 2017 14:31:11 +0000 Message-ID: To: IETF IPPM WG Cc: giuseppe.fioccola@telecomitalia.it, "sjacob@juniper.net" , "gbharat@juniper.net" , bill.wu@huawei.com Content-Type: multipart/alternative; boundary="001a114b16a6e51a020552f1ebf6" Archived-At: Subject: [ippm] draft-bhaprasud-ippm-pm-03 - Update X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jun 2017 14:31:26 -0000 --001a114b16a6e51a020552f1ebf6 Content-Type: text/plain; charset="UTF-8" Hi, All: We have updated the draft based on the comments raised in the last IETF meeting. *https://datatracker.ietf.org/doc/draft-bhaprasud-ippm-pm/ * This draft discuss some new methodology for performance measurements and provide fine granularity performance measurement based on COS and Color classification. Tracking of the performance of experienced by specific customer traffic. The main changes in v(-03)include: 1. Address the relationship with MEF work 2. Expand the scope to cover delay measurement and delay variation measurement. 3. Add more details to section 4. 4. Update definitions in the section 2. 5. Change the title to performance measurement model. Please review and post your comments. Regards, Praveen --001a114b16a6e51a020552f1ebf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi, A= ll:


We have updated the draft based on th= e comments raised in the last IETF meeting.

https://datatracker.iet= f.org/doc/draft-bhaprasud-ippm-pm/

This draft discuss some new methodology for performance measurements and=20 provide fine granularity performance measurement=C2=A0 based on COS and Col= or classification.

Tracking of the performance of experi= enced by specific customer traffic.

The main changes in v(-03)include:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Addres= s the relationship with MEF work

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expand= the scope to cover delay measurement and delay variation measurement.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Add mo= re details to section 4.

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Update= definitions in the section 2.

5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Change= the title to performance measurement model.


Please review and post your comm= ents.

Regards,
Praveen
--001a114b16a6e51a020552f1ebf6-- From nobody Tue Jun 27 11:01:24 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5641243F6; Tue, 27 Jun 2017 11:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 cxj-XytgfpJQ; Tue, 27 Jun 2017 11:01:19 -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 91E8D12EAEC; Tue, 27 Jun 2017 11:01:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJH28335; Tue, 27 Jun 2017 18:01:15 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 27 Jun 2017 19:01:14 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML703-CHM.china.huawei.com ([169.254.5.136]) with mapi id 14.03.0301.000; Tue, 27 Jun 2017 11:01:09 -0700 From: Haoyu song To: "Carlos Pignataro (cpignata)" CC: "ippm@ietf.org" , "draft-brockners-inband-oam-data.authors@ietf.org" Thread-Topic: draft on iOAM scalability improvement Thread-Index: AdLTH0fsZe3MoWIbQhuBeTS1CfmKpQb+nM0AAAzlYUD//64CAP//bVpg Date: Tue, 27 Jun 2017 18:01:09 +0000 Message-ID: <78A2745BE9B57D4F9D27F86655EB87F925957045@SJCEML702-CHM.china.huawei.com> References: <78A2745BE9B57D4F9D27F86655EB87F925845299@SJCEML701-CHM.china.huawei.com> <78A2745BE9B57D4F9D27F86655EB87F925956DE5@SJCEML702-CHM.china.huawei.com> <00D7469D-DBC6-4D86-A393-060A4A877FED@cisco.com> In-Reply-To: <00D7469D-DBC6-4D86-A393-060A4A877FED@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.175] Content-Type: multipart/alternative; boundary="_000_78A2745BE9B57D4F9D27F86655EB87F925957045SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59529D6C.0002, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 13a0c1d0bcaa62f7376adfb679cef4e0 Archived-At: Subject: Re: [ippm] draft on iOAM scalability improvement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jun 2017 18:01:22 -0000 --_000_78A2745BE9B57D4F9D27F86655EB87F925957045SJCEML702CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLA0KDQpXZSBoYXZlIGxpc3RlZCBxdWl0ZSBhIGZldyB1c2UgY2FzZXMgaW4gdGhl IGRyYWZ0LCBhbHRob3VnaCB0aG9zZSB1c2UgY2FzZXMgYXJlIG1vcmUgcXVhbGl0YXRpdmUgdGhh biBxdWFudGl0YXRpdmUgbm93LiAgUGxlYXNlIGxldCBtZSBrbm93IHdoYXQgc3BlY2lmaWMgaW5m b3JtYXRpb24geW91IHdhbnQgdG8gc2VlLg0KDQpXZSBoYXZlIGRvbmUgc29tZSByb3VnaCBhbmFs eXNpcyBvbiBpb2FtIGFwcGxpY2FiaWxpdHkgb24gZGlmZmVyZW50IHR5cGUgb2YgcGxhdGZvcm1z IGFuZCBkaWQgZmluZCBzb21lIHBlcmZvcm1hbmNlIGNvbmNlcm5zIGFzIGJlaW5nIGxhaWQgb3V0 IGluIHRoZSBkcmFmdC4gQnV0IHdlIHN0aWxsIG5lZWQgbW9yZSB0aW1lIHRvIGZpbmlzaCB0aGF0 IHdvcmsgYW5kIHdlIGFyZSBub3Qgc3VyZSB3aGljaCBsZXZlbCBvZiBkZXRhaWwgc2hvdWxkIGJl IGluY2x1ZGVkLg0KDQpXZSBjYW4gZGlzY3VzcyBtb3JlIGFib3V0IHRoaXMgZHVyaW5nIHRoZSBt ZWV0aW5nLiBUaGFua3MhDQoNCkhhb3l1DQoNCg0KRnJvbTogQ2FybG9zIFBpZ25hdGFybyAoY3Bp Z25hdGEpIFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KU2VudDogTW9uZGF5LCBKdW5lIDI2 LCAyMDE3IDc6MDQgUE0NClRvOiBIYW95dSBzb25nIDxoYW95dS5zb25nQGh1YXdlaS5jb20+DQpD YzogaXBwbUBpZXRmLm9yZzsgZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS5hdXRob3Jz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogZHJhZnQgb24gaU9BTSBzY2FsYWJpbGl0eSBpbXByb3Zl bWVudA0KDQpIaSwgSGFveXUsDQoNCk9uZSBvZiBteSBwb2ludHMgaXMgdGhhdCB0aGUgZHJhZnQg dGFsa3MgYWJvdXQgYSBudW1iZXIgb2Yg4oCcY29zdHPigJ0gKGluY2x1ZGluZyBhbHNvIHNpemUp IGJ1dCB3ZSBjYW5ub3Qgc2F5IGhvdyBuZWdsaWdpYmxlIG9yIG5vdCB0aGV5IGFyZSB1bnRpbCB3 ZSB1bmRlcnN0YW5kIHVuZGVyIHdoaWNoIHVzZSBjYXNlIHRoZXkgYXJlIGJlaW5nIGNvbnNpZGVy ZWQuDQoNCkxvb2sgZm9yd2FyZCB0byB5b3VyIG5leHQgdmVyc2lvbiwgYW5kIGluIHBhcnRpY3Vs YXIgdXNlLWNhc2UgYXBwbGljYWJpbGl0eSB0byB0aGUgZGlmZmVyZW50IGNvc3RzIGFuZCB0cmFk ZW9mZnMuIFRoYXQgd2F5LCB0aGUgV0cgd2lsbCBiZSBhYmxlIHRvIHNlZSB3aGVyZSB0byBmb2N1 cyB0aGUgbmVlZCBmb3IgcHJvdG9jb2wgZmxleGliaWxpdHkgKGF0IHRoZSBjb3N0IG9mIGNvbXBs ZXhpdHkpLg0KDQpUaGFua3MhDQoNCuKAlCBDYXJsb3MuDQoNCk9uIEp1biAyNiwgMjAxNywgYXQg OTo0OCBQTSwgSGFveXUgc29uZyA8aGFveXUuc29uZ0BodWF3ZWkuY29tPG1haWx0bzpoYW95dS5z b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgQ2FybG9zLA0KDQpUaGFuayB5b3UgZm9yIHRo ZSBjb21tZW50cyEgWW91IGFyZSByaWdodCB0aGF0IGluIHRoZSBkcmFmdCB3ZSBpbnRlbmQgdG8g ZGVzY3JpYmUgc29tZSBpbXBsZW1lbnRhdGlvbiB0cmFkZW9mZnMgZGVwZW5kaW5nIG9uIHRoZSBk YXRhIHBsYW5lIGNhcGFiaWxpdHkgYW5kIHRob3NlIHRyYWRlb2ZmcyBuZWVkIHRvIGFkZCBzb21l IGV4dHJhIGZsZXhpYmlsaXR5IHRvIHRoZSBjdXJyZW50IGlPQU0gaGVhZGVyIHNwZWNpZmljYXRp b24uDQpXaGlsZSBJT0FNIGRhdGEgaXMgdmVyeSB1c2VmdWwsIGl0cyBjb3N0IChiYW5kd2lkdGgg Y29uc3VtcHRpb24gYW5kIHByb2Nlc3NpbmcgcmVxdWlyZW1lbnRzKSBpcyBub3QgbmVnbGlnaWJs ZS4gVGhlIHByb3RvY29sIHNob3VsZCBzdHJpdmUgdG8gYWxsb3cgZ3JhY2VmdWwgdHJhZGVvZmZz IGF0IHRoZSBiZWdpbm5pbmcuIEnigJltIHdvcmtpbmcgb24gYSByZXZpc2lvbiBvZiB0aGUgZHJh ZnQgdG8gY2xhcmlmeSBpdC4gVGhhbmtzIQ0KDQpIYW95dQ0KDQoNCkZyb206IENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NClNlbnQ6IE1vbmRh eSwgSnVuZSAyNiwgMjAxNyA1OjQ4IFBNDQpUbzogSGFveXUgc29uZyA8aGFveXUuc29uZ0BodWF3 ZWkuY29tPG1haWx0bzpoYW95dS5zb25nQGh1YXdlaS5jb20+Pg0KQ2M6IGlwcG1AaWV0Zi5vcmc8 bWFpbHRvOmlwcG1AaWV0Zi5vcmc+OyBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhLmF1 dGhvcnNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEuYXV0 aG9yc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBkcmFmdCBvbiBpT0FNIHNjYWxhYmlsaXR5IGlt cHJvdmVtZW50DQoNCkhhb3l1LA0KDQpUaGFuayB5b3UgZm9yIHNoYXJpbmcgYSB2ZXJ5IHdlbGwg d3JpdHRlbiBkcmFmdCDigJQgYm90aCBpbiBjb250ZW50IGFuZCBmb3JtYXQhDQoNClRoZSB3YXkg aW4gd2hpY2ggSSBzZWUgdGhlIGFuYWx5c2lzIHByZXNlbnRlZCwgaG93ZXZlciwgaXMgYSBiaXQg ZGlmZmVyZW50IHRoYW4g4oCcc2NhbGFiaWxpdHkgbGltaXRhdGlvbnPigJ0uIEkgYmVsaWV2ZSB0 aGVzZSBwcm9wb3NhbHMgYXJlIG9wdGltaXphdGlvbnMgZm9yIHNwZWNpZmljIHNjYWxpbmcgcmVx dWlyZW1lbnRzIG9yIGZvciBwYXJ0aWN1bGFyIHVzZSBjYXNlcy4gSW4gZmFjdCwgdGhpcyBkcmFm dCBzZWVtcyB0byBkZXNjcmliZSB0cmFkZW9mZnMg4oCUIGFuZCBob3cgdG8gcG9uZGVyIHRoZSB3 ZWlnaHRzIChwcmVjaXNpb24sIHBhayBzaXplLCBwcm9jZXNzaW5nKSBkZXBlbmRzIG9uIHRoZSB1 c2UgY2FzZSBhbmQgd2hhdCB0byBvcHRpbWl6ZSAoYXMgb3Bwb3NlZCB0byBhIHJpZ2h0IHZzLiB3 cm9uZyBhbnN3ZXIpLg0KDQpTbywgdW5kZXIgd2hpY2ggY29uZGl0aW9ucyBkbyB5b3Ugc2VlIHRo ZXNlIGFzIHVzZWZ1bD8NCg0KVGhhbmtzIQ0KDQrigJQgQ2FybG9zLg0KDQpPbiBNYXkgMjIsIDIw MTcsIGF0IDE6MjIgUE0sIEhhb3l1IHNvbmcgPGhhb3l1LnNvbmdAaHVhd2VpLmNvbTxtYWlsdG86 aGFveXUuc29uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQoNCkRlYXIgYWxsLA0KDQpXZSBoYXZlIHN1 Ym1pdHRlZCBhbiBpT0FNIHJlbGF0ZWQgZHJhZnQgYXMgZm9sbG93cy4gIFBsZWFzZSBraW5kbHkg cHJvdmlkZSAgY29tbWVudHMgYW5kIGFsc28gbGV0IHVzIGtub3cgaWYgeW91IGhhdmUgYW55IHF1 ZXN0aW9ucyB3aGljaCB3aWxsIGhlbHAgdXMgY29udGludWUgdG8gaW1wcm92ZSB0aGUgZHJhZnQu IFRoYW5rIHlvdSB2ZXJ5IG11Y2ghDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXNvbmctaXBwbS1pb2FtLXNjYWxhYmlsaXR5Lw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIHNldmVyYWwgc2NhbGFiaWxpdHkgaXNzdWVzIGluIGN1cnJlbnQg aW4tc2l0dQ0KICAgT0FNIGRvY3VtZW50cyBhbmQgcHJvcG9zZXMgY29ycmVzcG9uZGluZyBzb2x1 dGlvbnMuICBTcGVjaWZpY2FsbHksIHdlDQogICBleHRlbmQgaW4tc2l0dSBPQU0gdG8gc3VwcG9y dCBtb3JlIHN0YW5kYXJkIHRyYWNpbmcgZGF0YSB0aGFuIGlzDQogICBjdXJyZW50bHkgZGVmaW5l ZCBhbmQgYWRkIG5ldyBmZWF0dXJlcyB0byBhdm9pZCBsaW1pdGF0aW9ucyBvbiBNVFUsDQogICBi YW5kd2lkdGgsIGZvcndhcmRpbmcgcGF0aCBsZW5ndGgsIGFuZCBub2RlIHByb2Nlc3NpbmcgY2Fw YWJpbGl0eS4NCg0KDQpIYW95dQ0KDQo= --_000_78A2745BE9B57D4F9D27F86655EB87F925957045SJCEML702CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxl LWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkg Q2FybG9zLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgaGF2 ZSBsaXN0ZWQgcXVpdGUgYSBmZXcgdXNlIGNhc2VzIGluIHRoZSBkcmFmdCwgYWx0aG91Z2ggdGhv c2UgdXNlIGNhc2VzIGFyZSBtb3JlIHF1YWxpdGF0aXZlIHRoYW4gcXVhbnRpdGF0aXZlIG5vdy4N CjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+Jm5ic3A7UGxlYXNlIGxldCBtZSBrbm93IHdoYXQg c3BlY2lmaWMgaW5mb3JtYXRpb24geW91IHdhbnQgdG8gc2VlLjxvOnA+PC9vOnA+PC9hPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIGhhdmUgZG9uZSBzb21lIHJvdWdoIGFuYWx5 c2lzIG9uIGlvYW0gYXBwbGljYWJpbGl0eSBvbiBkaWZmZXJlbnQgdHlwZSBvZiBwbGF0Zm9ybXMg YW5kIGRpZCBmaW5kIHNvbWUgcGVyZm9ybWFuY2UgY29uY2VybnMgYXMgYmVpbmcgbGFpZCBvdXQg aW4gdGhlIGRyYWZ0LiBCdXQNCiB3ZSBzdGlsbCBuZWVkIG1vcmUgdGltZSB0byBmaW5pc2ggdGhh dCB3b3JrIGFuZCB3ZSBhcmUgbm90IHN1cmUgd2hpY2ggbGV2ZWwgb2YgZGV0YWlsIHNob3VsZCBi ZSBpbmNsdWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldl IGNhbiBkaXNjdXNzIG1vcmUgYWJvdXQgdGhpcyBkdXJpbmcgdGhlIG1lZXRpbmcuIFRoYW5rcyE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhhb3l1DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0bzpjcGlnbmF0YUBjaXNjby5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdW5lIDI2LCAyMDE3IDc6MDQgUE08YnI+ DQo8Yj5Ubzo8L2I+IEhhb3l1IHNvbmcgJmx0O2hhb3l1LnNvbmdAaHVhd2VpLmNvbSZndDs8YnI+ DQo8Yj5DYzo8L2I+IGlwcG1AaWV0Zi5vcmc7IGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRh dGEuYXV0aG9yc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogZHJhZnQgb24gaU9B TSBzY2FsYWJpbGl0eSBpbXByb3ZlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpLCZuYnNwO0hhb3l1LCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBvZiBteSBwb2ludHMgaXMgdGhhdCB0aGUgZHJhZnQg dGFsa3MgYWJvdXQgYSBudW1iZXIgb2Yg4oCcY29zdHPigJ0gKGluY2x1ZGluZyBhbHNvIHNpemUp IGJ1dCB3ZSBjYW5ub3Qgc2F5IGhvdyBuZWdsaWdpYmxlIG9yIG5vdCB0aGV5IGFyZSB1bnRpbCB3 ZSB1bmRlcnN0YW5kIHVuZGVyIHdoaWNoIHVzZSBjYXNlIHRoZXkgYXJlIGJlaW5nIGNvbnNpZGVy ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkxvb2sgZm9yd2FyZCB0byB5b3VyIG5leHQgdmVyc2lvbiwgYW5kIGluIHBhcnRpY3VsYXIgdXNl LWNhc2UgYXBwbGljYWJpbGl0eSB0byB0aGUgZGlmZmVyZW50IGNvc3RzIGFuZCB0cmFkZW9mZnMu IFRoYXQgd2F5LCB0aGUgV0cgd2lsbCBiZSBhYmxlIHRvIHNlZSB3aGVyZSB0byBmb2N1cyB0aGUg bmVlZCBmb3IgcHJvdG9jb2wgZmxleGliaWxpdHkgKGF0IHRoZSBjb3N0IG9mIGNvbXBsZXhpdHkp LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPuKAlCBDYXJsb3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBKdW4gMjYsIDIwMTcsIGF0IDk6NDggUE0sIEhhb3l1IHNvbmcgJmx0 OzxhIGhyZWY9Im1haWx0bzpoYW95dS5zb25nQGh1YXdlaS5jb20iPmhhb3l1LnNvbmdAaHVhd2Vp LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIENhcmxvcyw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzISBZb3UgYXJlIHJpZ2h0IHRoYXQg aW4gdGhlIGRyYWZ0IHdlIGludGVuZCB0byBkZXNjcmliZSBzb21lIGltcGxlbWVudGF0aW9uIHRy YWRlb2ZmcyBkZXBlbmRpbmcgb24gdGhlIGRhdGEgcGxhbmUgY2FwYWJpbGl0eSBhbmQgdGhvc2UN CiB0cmFkZW9mZnMgbmVlZCB0byBhZGQgc29tZSBleHRyYSBmbGV4aWJpbGl0eSB0byB0aGUgY3Vy cmVudCBpT0FNIGhlYWRlciBzcGVjaWZpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5XaGlsZSBJT0FNIGRhdGEgaXMgdmVyeSB1c2VmdWwsIGl0cyBjb3N0IChiYW5kd2lk dGggY29uc3VtcHRpb24gYW5kIHByb2Nlc3NpbmcgcmVxdWlyZW1lbnRzKSBpcyBub3QgbmVnbGln aWJsZS4gVGhlIHByb3RvY29sIHNob3VsZCBzdHJpdmUgdG8gYWxsb3cgZ3JhY2VmdWwgdHJhZGVv ZmZzDQogYXQgdGhlIGJlZ2lubmluZy4gSeKAmW0gd29ya2luZyBvbiBhIHJldmlzaW9uIG9mIHRo ZSBkcmFmdCB0byBjbGFyaWZ5IGl0LiBUaGFua3MhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IYW95dTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkNhcmxvcw0KIFBpZ25hdGFybyAoY3BpZ25hdGEpIFs8YSBocmVmPSJtYWlsdG86 Y3BpZ25hdGFAY2lzY28uY29tIj5tYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tPC9hPl08c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRh eSwgSnVuZSAyNiwgMjAxNyA1OjQ4IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5IYW95dSBzb25nICZsdDs8YSBocmVmPSJt YWlsdG86aGFveXUuc29uZ0BodWF3ZWkuY29tIj5oYW95dS5zb25nQGh1YXdlaS5jb208L2E+Jmd0 Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciPmlwcG1AaWV0Zi5vcmc8L2E+ Ow0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEuYXV0aG9y c0BpZXRmLm9yZyI+ZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS5hdXRob3JzQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogZHJhZnQgb24gaU9BTSBzY2FsYWJpbGl0eSBpbXByb3Zl bWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhb3l1LDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBmb3Ig c2hhcmluZyBhIHZlcnkgd2VsbCB3cml0dGVuIGRyYWZ0IOKAlCBib3RoIGluIGNvbnRlbnQgYW5k IGZvcm1hdCE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHdheSBpbiB3aGljaCBJIHNl ZSB0aGUgYW5hbHlzaXMgcHJlc2VudGVkLCBob3dldmVyLCBpcyBhIGJpdCBkaWZmZXJlbnQgdGhh biDigJxzY2FsYWJpbGl0eSBsaW1pdGF0aW9uc+KAnS4gSSBiZWxpZXZlIHRoZXNlIHByb3Bvc2Fs cyBhcmUgb3B0aW1pemF0aW9ucyBmb3Igc3BlY2lmaWMgc2NhbGluZyByZXF1aXJlbWVudHMgb3Ig Zm9yIHBhcnRpY3VsYXIgdXNlIGNhc2VzLiBJbiBmYWN0LCB0aGlzIGRyYWZ0IHNlZW1zDQogdG8g ZGVzY3JpYmUgdHJhZGVvZmZzIOKAlCBhbmQgaG93IHRvIHBvbmRlciB0aGUgd2VpZ2h0cyAocHJl Y2lzaW9uLCBwYWsgc2l6ZSwgcHJvY2Vzc2luZykgZGVwZW5kcyBvbiB0aGUgdXNlIGNhc2UgYW5k IHdoYXQgdG8gb3B0aW1pemUgKGFzIG9wcG9zZWQgdG8gYSByaWdodCB2cy4gd3JvbmcgYW5zd2Vy KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIHVuZGVyIHdoaWNoIGNvbmRpdGlvbnMg ZG8geW91IHNlZSB0aGVzZSBhcyB1c2VmdWw/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rcyE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCUIENhcmxvcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIE1heSAyMiwgMjAxNywgYXQgMToyMiBQTSwgSGFveXUgc29uZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmhhb3l1LnNvbmdAaHVhd2VpLmNvbSI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aGFveXUuc29uZ0BodWF3ZWkuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZWFyIGFsbCw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+V2UgaGF2ZSBzdWJtaXR0ZWQgYW4gaU9BTSByZWxhdGVkIGRyYWZ0IGFzIGZvbGxvd3Mu ICZuYnNwO1BsZWFzZSBraW5kbHkgcHJvdmlkZSAmbmJzcDtjb21tZW50cyBhbmQgYWxzbyBsZXQg dXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIHdoaWNoIHdpbGwgaGVscCB1cyBjb250 aW51ZSB0byBpbXByb3ZlIHRoZQ0KIGRyYWZ0LiBUaGFuayB5b3UgdmVyeSBtdWNoITwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1zb25nLWlwcG0taW9hbS1zY2FsYWJpbGl0eS8iPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0Rjcy Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zb25nLWlwcG0taW9hbS1z Y2FsYWJpbGl0eS88L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BYnN0cmFjdDo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBzZXZlcmFsIHNjYWxhYmlsaXR5IGlzc3VlcyBpbiBjdXJyZW50IGluLXNpdHU8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBPQU0gZG9jdW1lbnRz IGFuZCBwcm9wb3NlcyBjb3JyZXNwb25kaW5nIHNvbHV0aW9ucy4mbmJzcDsgU3BlY2lmaWNhbGx5 LCB3ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IGV4dGVu ZCBpbi1zaXR1IE9BTSB0byBzdXBwb3J0IG1vcmUgc3RhbmRhcmQgdHJhY2luZyBkYXRhIHRoYW4g aXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBjdXJyZW50 bHkgZGVmaW5lZCBhbmQgYWRkIG5ldyBmZWF0dXJlcyB0byBhdm9pZCBsaW1pdGF0aW9ucyBvbiBN VFUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgYmFuZHdp ZHRoLCBmb3J3YXJkaW5nIHBhdGggbGVuZ3RoLCBhbmQgbm9kZSBwcm9jZXNzaW5nIGNhcGFiaWxp dHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+SGFveXU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_78A2745BE9B57D4F9D27F86655EB87F925957045SJCEML702CHMchi_-- From nobody Wed Jun 28 05:47:57 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B277120454; Wed, 28 Jun 2017 05:47:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qEDkmGEuCXQd; Wed, 28 Jun 2017 05:47:42 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD11126C7A; Wed, 28 Jun 2017 05:47:42 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id e201so18630398ybb.1; Wed, 28 Jun 2017 05:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=96Cd5VD9XNBKOCP0O/4h6JA6UHHDNYf4w1TX9ND1V5k=; b=kwyGKwggtGsR48q5BM86T9kr78A5kOz52oJGqscqtPBV7rIoU9y2h4ttvqiCbVvBx3 Ca05ave7H5IIwFJwQWCgGzdIYFHayMfgzFvDWARWsfXC7/sYwbQIIdLZJ0pm3WC2uQ7j KB/mT6pDkIL4J+LyALtmEqUDHhatzgdcaS9w7O82wwdjy2xGSIBGjRNlY79rxbhgzOzd j28q0OMTZ8sroTilhZYnPDmWBkHyXCgn2mbki+d29xq/rwH0kAO8cinJlMAoYjKpp4HW NQ9CYqsmBiJfPsTf6WKnlYOvhv2vMf+yCjK7I7noYOpUNg4xt38Z/2fmdHsPrRT+Sm0G 2OHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=96Cd5VD9XNBKOCP0O/4h6JA6UHHDNYf4w1TX9ND1V5k=; b=pEJ8dwMXpd9Ao2duEo9+e3+pzBx6T9aDT9thC7pDwjj1U+DQq1IGQFCUQuq76JUmdV LLTlwzrcoeFc67MlhFj02QH6qs8plk1/etSM21t6MBNThuYwzJhlYgZ6boFPtsLzr0I0 IBQIAK5SFVdqH4GA0f0tD9QLIpSob90I4TXVhMWYqyqDDYHfqnFbGOxvI8cBaulvbbj1 R+1TXnpaFcnZbCDuyPo9oqJDLYLT1QI9Ifqlf/SYNnKlo/AkTjFCxGiH7jItcBfNP9Oa iDssZ1B6Y3PeevfEdwNPYDjCKTyREsU1XDBHuoxTIFyLDz3xyi+762E94J0v+eQVI6Kr xvFg== X-Gm-Message-State: AKS2vOy4yq1HkjnR0hmbulsUU04pheYrTK+iU4jSLMazDpJS/IvlA5FN Y1dbKvF6EIvhKfgga1/qcDy7wd6jKA== X-Received: by 10.37.246.18 with SMTP id t18mr8087381ybd.211.1498654061170; Wed, 28 Jun 2017 05:47:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.104.144 with HTTP; Wed, 28 Jun 2017 05:47:40 -0700 (PDT) Received: by 10.37.104.144 with HTTP; Wed, 28 Jun 2017 05:47:40 -0700 (PDT) In-Reply-To: <149849652284.18472.5189755418267981271@ietfa.amsl.com> References: <149849652284.18472.5189755418267981271@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 28 Jun 2017 07:47:40 -0500 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, ippm@ietf.org Content-Type: multipart/alternative; boundary="f403045da836f519cb05530496b7" Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-6man-pdm-option-13.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jun 2017 12:47:45 -0000 --f403045da836f519cb05530496b7 Content-Type: text/plain; charset="UTF-8" Just to let the working group know. On Jun 26, 2017 12:02, wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics of the IETF. Title : IPv6 Performance and Diagnostic Metrics (PDM) Destination Option Authors : Nalini Elkins Robert M. Hamilton Michael S. Ackermann Filename : draft-ietf-ippm-6man-pdm-option-13.txt Pages : 32 Date : 2017-06-26 Abstract: To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real-time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) destination options extension header. The field limits, calculations, and usage in measurement of PDM are included in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-13 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-6man-pdm-option-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-6man-pdm-option-13 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/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm I'm at a campsite with minimal cellular coverage this week, but I'll follow up when that changes. And thanks for the revision. Spencer --f403045da836f519cb05530496b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to let the working group know.

On Jun 26, 2017 12:02, <internet-drafts@ietf.org> = wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IP Performance Metrics of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nali= ni Elkins
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Robert M. Hamilton
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Michael S. Ackermann
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ippm-6man-pdm-option-13.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-26

Abstract:
=C2=A0 =C2=A0To assess performance problems,=C2=A0 this document describes = optional
=C2=A0 =C2=A0headers embedded in each packet that provide sequence numbers = and
=C2=A0 =C2=A0timing information as a basis for measurements.=C2=A0 Such mea= surements
=C2=A0 =C2=A0may be interpreted in real-time or after the fact. This docume= nt
=C2=A0 =C2=A0specifies the Performance and Diagnostic Metrics (PDM) destina= tion
=C2=A0 =C2=A0options extension header. The field limits, calculations, and = usage
=C2=A0 =C2=A0in measurement of PDM are included in this document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/d= oc/draft-ietf-ippm-6man-pdm-option/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft= -ietf-ippm-6man-pdm-option-13
https://datatracker.ietf.org= /doc/html/draft-ietf-ippm-6man-pdm-option-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?<= wbr>url2=3Ddraft-ietf-ippm-6man-pdm-option-13


Please note that it may take a couple of minutes from the time of submissio= n
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/

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

= I'm at a campsite with minimal cellular coverage this week, but I'l= l follow up when that changes. And thanks for the revision.

Spencer
--f403045da836f519cb05530496b7-- From nobody Wed Jun 28 11:35:58 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AF112EBF5 for ; Wed, 28 Jun 2017 11:35:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9r3kad-gXDeg for ; Wed, 28 Jun 2017 11:35:44 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0851512EC76 for ; Wed, 28 Jun 2017 11:35:44 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id q86so37547164pfl.3 for ; Wed, 28 Jun 2017 11:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Wj5Fo3a/SQi/glGjL7STP0ZBktTyyGcTlgUOVVQrk0Q=; b=p/h3aJaN7v5yKSQf2UN9pyu3TFkHnMmbhHMg6DN0kLTp1viOWdwln5Qxg/ku0rjSoR D/rikzSi8EqRfhWhX/qURg8QA0OSMF6eyxUeQp9Bn/c1wlPeE8e5PzAIT9xxr5MlDD5/ DNQP7rstLP5rsRKfG6K3SnbuR4cBIqylQB9UayLIIcKOZdUs7646NKlRBLu6n+SgocYP /+aNCnpmOhuF6BmEzzn64rT4Z7zr2sUuBYUix0QmVFSS/a4wCHQEoftCnnQ5JHT1z3zY SfK9oCHRCNRIcfHHfA/EJfNdj6ruyisdgxZsmowVBlTsDOsb6MHBZSUAl0NnSl42qWet 6djQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Wj5Fo3a/SQi/glGjL7STP0ZBktTyyGcTlgUOVVQrk0Q=; b=cePwItX6sQwE0y+jUGn8dc7t9IEP8ZimrqM/kbzuW4Cn+fMLiy1f1igAG4YkNzRuzy GquFtaS+rq7fzEYf47O30m0kFuMYB55vTAwr9shwNn8cqhc6ux854ruMTPhvKc5pA79+ boc6e9ENtdao0v/pIi8nvHOkxO8FnkICK0Ms9uR5snGKtp7Z7iMvvr9E3iILJxQBXX5O ZOa+KPjD5Yb+csWNepIz+K+iL37y6LIO3f12lLs/OfcBcxt+WJuASKysd0M9pDaDb+Ag sw11WcuXUVN9roXWq6HM7BGhlN20gOF3VHEv/bRrrDwW80Yu8B2PXryLqivu1zN5kKzE 2KZg== X-Gm-Message-State: AKS2vOxQHEa0dujl+sgKa3w7qNVoTmOSnsi5IWDTiMMlUgEyWR4Xr9fv o7NqYc767IcREuuWNUR7TCXRoDpwaw== X-Received: by 10.99.126.8 with SMTP id z8mr11994252pgc.149.1498674943428; Wed, 28 Jun 2017 11:35:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.163.236 with HTTP; Wed, 28 Jun 2017 11:35:42 -0700 (PDT) In-Reply-To: <149741226972.7628.7734215311593851926.idtracker@ietfa.amsl.com> References: <149741226972.7628.7734215311593851926.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Wed, 28 Jun 2017 11:35:42 -0700 Message-ID: To: "ippm@ietf.org" Content-Type: multipart/alternative; boundary="f403045dc1eaa30b89055309734b" Archived-At: Subject: [ippm] Fwd: New Version Notification for draft-mirsky-ippm-twamp-light-yang-09.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jun 2017 18:35:47 -0000 --f403045dc1eaa30b89055309734b Content-Type: text/plain; charset="UTF-8" Dear All, the new version includes three configurable percentile levels with 95, 99, and 99.9 being respective default values. Percentiles reported for delay and delay variation metrics - far-, near-end, and round-trip. Appreciate your comments, suggestions. Regards, Greg ---------- Forwarded message ---------- From: Date: Tue, Jun 13, 2017 at 8:51 PM Subject: New Version Notification for draft-mirsky-ippm-twamp-light-yang-09.txt To: Adrian Pan , Min Xiao , Gregory Mirsky , Wei S Luo A new version of I-D, draft-mirsky-ippm-twamp-light-yang-09.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-ippm-twamp-light-yang Revision: 09 Title: Two-Way Active Measurement Protocol (TWAMP) Light Data Model Document date: 2017-06-13 Group: Individual Submission Pages: 30 URL: https://www.ietf.org/internet-drafts/draft-mirsky-ippm- twamp-light-yang-09.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-ippm-twamp- light-yang/ Htmlized: https://tools.ietf.org/html/draft-mirsky-ippm-twamp-light- yang-09 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-ippm- twamp-light-yang-09 Diff: https://www.ietf.org/rfcdiff?url2=draft-mirsky-ippm-twamp- light-yang-09 Abstract: This document specifies the data model for implementations of Session-Sender and Session-Reflector for Two-Way Active Measurement Protocol (TWAMP) Light mode using YANG. 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. The IETF Secretariat --f403045dc1eaa30b89055309734b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
the new version includes three configurable = percentile levels with 95, 99, and 99.9 being respective default values. Pe= rcentiles reported for delay and delay variation metrics - far-, near-end, = and round-trip.

Appreciate your comments, suggesti= ons.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Tue, J= un 13, 2017 at 8:51 PM
Subject: New Version Notification for draft-mirsk= y-ippm-twamp-light-yang-09.txt
To: Adrian Pan <adrian.pan@ericsson.com>, Min Xiao <xiao.min2@zte.com.cn>, Gregory Mirs= ky <gregimirsky@gmail.com&g= t;, Wei S Luo <wei.s.luo@erics= son.com>



A new version of I-D, draft-mirsky-ippm-twamp-light-yang-09.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-ippm-twamp-light= -yang
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A009
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Two-Way Active Measurement Protoco= l (TWAMP) Light Data Model
Document date:=C2=A0 2017-06-13
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 30
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mir= sky-ippm-twamp-light-yang-09.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-ippm-twamp-light-yang/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mirsky-ippm-twamp-light-yang-0= 9
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-ippm-twamp-light-yang-09
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-ip= pm-twamp-light-yang-09

Abstract:
=C2=A0 =C2=A0This document specifies the data model for implementations of<= br> =C2=A0 =C2=A0Session-Sender and Session-Reflector for Two-Way Active Measur= ement
=C2=A0 =C2=A0Protocol (TWAMP) Light mode using YANG.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--f403045dc1eaa30b89055309734b-- From nobody Wed Jun 28 18:11:56 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3619126C83; Wed, 28 Jun 2017 18:11:54 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 8OCs_gzG9vuG; Wed, 28 Jun 2017 18:11:53 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 44E101200C5; Wed, 28 Jun 2017 18:11:53 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5T15kwJ022817; Wed, 28 Jun 2017 21:11:51 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0048589.ppops.net-00191d01. with ESMTP id 2bcm33422q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Jun 2017 21:11:50 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v5T1Bn8p087940; Wed, 28 Jun 2017 20:11:49 -0500 Received: from dalint02.pst.cso.att.com (dalint02.pst.cso.att.com [135.31.133.160]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v5T1BheJ087921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Jun 2017 20:11:43 -0500 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by dalint02.pst.cso.att.com (RSA Interceptor); Thu, 29 Jun 2017 01:10:15 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v5T1AFlw007125; Wed, 28 Jun 2017 20:10:15 -0500 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v5T1A7Qt006542; Wed, 28 Jun 2017 20:10:07 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id 3CDF6E0A03; Wed, 28 Jun 2017 21:10:06 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Wed, 28 Jun 2017 21:10:06 -0400 From: "MORTON, ALFRED C (AL)" To: "ippm@ietf.org" CC: "ippm-chairs@ietf.org" Thread-Topic: New draft on Advanced Route Metrics and Measurements Thread-Index: AdLwc1WSB70hnm82ToejYJQjP5zb/w== Date: Thu, 29 Jun 2017 01:10:05 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25FE7B3E@njmtexg5.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.215.169] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-29_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706290016 Archived-At: Subject: [ippm] New draft on Advanced Route Metrics and Measurements X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 01:11:55 -0000 IPPM, Back at IETF-95 in Buenos Aires, the IPPM WG wanted to see some "traceroute" support in the Registry, but we didn't even have a metric to reference. Many methods were available, producing differing results. Now, with in-situ OAM, it's possible that there will=20 be more advanced methods of measurement than ever before. There are also some interesting RTD analysis=20 possibilities which we describe. We've been working on this draft in fits and starts since meeting in "BA". We invite IPPM'ers to read our draft and share your=20 reactions and comments here. thanks and regards, Ignacio, Joachim, and Al -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Advanced Unidirectional Route Assessment Authors : Jos=E9 Ignacio Alvarez-Hamelin Al Morton Joachim Fabini Filename : draft-amf-ippm-route-00.txt Pages : 17 Date : 2017-06-28 Abstract: This memo introduces an advanced unidirectional route assessment metric and associated measurement methodology, based on the IP Performance Metrics (IPPM) Framework RFC 2330. This memo updates RFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths. https://tools.ietf.org/html/draft-amf-ippm-route-00 From nobody Thu Jun 29 03:05:16 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68129129436; Thu, 29 Jun 2017 03:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 VzE5l_RSphJL; Thu, 29 Jun 2017 03:05:12 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [80.149.113.196]) (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 A865F12EC00; Thu, 29 Jun 2017 03:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1498730712; x=1530266712; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/5DKRhrpKOIqF2bUPHaNoFGmgricrWcy2FzbUIsrP6U=; b=1fhEkMPdu5unZne8+bLRHxyxAfPAWMj0wEbcwt7NlJHxlSOwJyfuO+y+ cmm7r/tDYrsJGWPmCnwoQvsvSEkXVE+ehhpltf7hRO6aaP3oGq5i3sHmT ULZOMNIYAJskRmxWE2k/svjcTmBTYdpkhFAOQru6kM0j+x+BdiuJiqPZv VcJ8EOJ2WMQcC7nIpN8RyUp/rY1p5vID3jnZ8/+sTP6hwtOoH2QQuDT4K Gik4BkmHX817C7GK9PbBfvS4lhFBCMseYmzUkQCBWCzeilJYLK7Mcid2b lzQ+sSAszweEZVvltnfgrCl7pIERu0NWPaT6PElMcMQstRX6cBrYDM+22 w==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT31.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 12:05:09 +0200 X-IronPort-AV: E=Sophos;i="5.40,280,1496095200"; d="scan'208";a="1348197040" Received: from he101653.emea1.cds.t-internal.com ([10.134.226.13]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 12:04:42 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101653.emea1.cds.t-internal.com (10.134.226.13) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 29 Jun 2017 12:04:33 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1263.000; Thu, 29 Jun 2017 12:04:33 +0200 From: To: CC: , Thread-Topic: New draft on Advanced Route Metrics and Measurements Thread-Index: AdLwc1WSB70hnm82ToejYJQjP5zb/wASQgLA Date: Thu, 29 Jun 2017 10:04:33 +0000 Message-ID: <03b0eab95a1f4c10930756248ace669a@HE101653.emea1.cds.t-internal.com> References: <4D7F4AD313D3FC43A053B309F97543CF25FE7B3E@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25FE7B3E@njmtexg5.research.att.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.169.89] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] New draft on Advanced Route Metrics and Measurements X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 10:05:14 -0000 Hi Al, I briefly read the draft. Reliably tracing one or more IP paths is a reason= able aim. Some comments: - this is a standards track doc containing no requirement language. - if this remains a standards track doc, the guidance on how to code packet= s must be well defined.=20 For the time being, a reader has an impression what to do, and an expert= may indeed do so. - the draft does not differentiate between equal paths along different rout= ers and equal paths=20 between the same pair of routers (i.e. multiple parallel links). I think= , the latter can't be detected.=20 This should be clarified. - It is not clear how in-band-oam can be combined or used to complete the a= dvanced route metrics.=20 Especially the multi-domain and single-domain measurement should be deco= upled more=20 clearly. - If the authors think that the guidance "change several fields to keep the= checksum of different=20 packets identical" doesn't require any security discussion, the authors = should say so in the=20 security section. Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: ippm [mailto:ippm-bounces@ietf.org] Im Auftrag von MORTON, ALFRED C (A= L) Gesendet: Donnerstag, 29. Juni 2017 03:10 An: ippm@ietf.org Cc: ippm-chairs@ietf.org Betreff: [ippm] New draft on Advanced Route Metrics and Measurements IPPM, Back at IETF-95 in Buenos Aires, the IPPM WG wanted to see some "traceroute= " support in the Registry, but we didn't even have a metric to reference. Many methods were available, producing differing results. Now, with in-situ OAM, it's possible that there will be more advanced metho= ds of measurement than ever before. There are also some interesting RTD analysis possibilities which we describ= e. We've been working on this draft in fits and starts since meeting in "BA= ". We invite IPPM'ers to read our draft and share your reactions and comments = here. thanks and regards, Ignacio, Joachim, and Al -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Advanced Unidirectional Route Assessment Authors : Jos=E9 Ignacio Alvarez-Hamelin Al Morton Joachim Fabini Filename : draft-amf-ippm-route-00.txt Pages : 17 Date : 2017-06-28 Abstract: This memo introduces an advanced unidirectional route assessment metric and associated measurement methodology, based on the IP Performance Metrics (IPPM) Framework RFC 2330. This memo updates RFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths. https://tools.ietf.org/html/draft-amf-ippm-route-00 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Thu Jun 29 06:39:05 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147D212EC40; Thu, 29 Jun 2017 06:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 iFWNPKAL-1PS; Thu, 29 Jun 2017 06:39:00 -0700 (PDT) Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (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 33B7512EC30; Thu, 29 Jun 2017 06:38:55 -0700 (PDT) X-AuditID: d9a97916-eb3ff70000000fa8-b6-595502ecd0dc Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id 29.01.04008.CE205595; Thu, 29 Jun 2017 15:38:52 +0200 (CEST) From: Fioccola Giuseppe To: "ippm@ietf.org" , "ippm-chairs@ietf.org" CC: "draft-fioccola-ippm-multipoint-alt-mark@ietf.org" Thread-Topic: [ippm] New draft on Multipoint Alternate Marking method Thread-Index: AdLw1tDPnMYxZOf+TOWhqQu62WfLLQ== Date: Thu, 29 Jun 2017 13:38:52 +0000 Message-ID: <93108cfef41c4cfb944883423a2a1766@TELMBXB02RM001.telecomitalia.local> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.231] x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_93108cfef41c4cfb944883423a2a1766TELMBXB02RM001telecomit_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsXCxfdHWvcNU2ikwYdPNhY7GyaxW6ze0c1m 0fPgHbMDs8eSJT+ZAhijGhhtEvPy8ksSS1IVUlKLk22VXDKLk3MSM3NTixRCUnNSk/NzlRQy U2yVjJUUCnISk1NzU/NKbJUSCwpS81KU7LgUMIANUFlmnkJqXnJ+SmZeuq2SZ7C/roWFqaWu oZJdYGlqcUm+Qm5qcXFienpmvkJqwnrBjH8L/AruplU09h1maWCcFN3FyMkhIWAicbJjCmMX IxeHkMBUJonft8+xgyTYBGwkDr46wQZiiwiESCy/upS1i5GDg1kgW+JcrxVIWFjAQeLa5j4m kLCIgKvE6StuENV6Emf+fgDrZBFQlejfPRFsIq9AoETvqaVgNqOArMSE3YsYQWxmAXGJF9NP sEOcIyCxZM95ZghbVOLl43+sELaBxNal+1ggbEWJ7qO9UDUyEguPTGaFmJMv8WjpDFaIXYIS J2c+YZnAKDwLyYpZSMpmISmDiOtJ3Jg6hQ3C1pZYtvA1M4StKzHj3yEWZPEFjOyrGEVzKwyM 9EogkZdZkpiTmaiXWbKJEZgobq6sFNvB2LrW+RCjAAejEg/vsS8hkUKsiWXFlbmHGCU4mJVE eFX/AoV4UxIrq1KL8uOLSnNSiw8x+gBDbCKzlGhyPjCJ5ZXEG5pYWBoaW1gYGVqYmeIQVhLn vZ4YHCkkkA5MXdmpqQWpRTDjmDg4pRoY2R9febA/7P22TOel5/eXFD1yjJyuFmSuZuZuPLtY +FOp8opFH6T+llS93D711btlB/RyXqp4BD5Z+HSZrrxlt4Od6VzHcKP32hH/TrkI57XelLG5 ZyxZJqvhzf1jP9M75xlfw3vPac7uP3M8sjB53uUNOvLfpBKONPbJOkdlqT5NZDO43HFCiaU4 I9FQi7moOBEAHlK+r0EDAAA= Archived-At: Subject: [ippm] New draft on Multipoint Alternate Marking method X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 13:39:03 -0000 --_000_93108cfef41c4cfb944883423a2a1766TELMBXB02RM001telecomit_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi IPPMers, Following the progress of the draft-ietf-ippm-alt-mark, that describes the a= lternate marking technology in a point-to-point scenario, we introduce this= new draft, that is a generalization of the methodology in order to measure= any kind of unicast flow in a multipoint-to-multipoint scenario. The -00 version is focused on the network clustering technique, that has to= be considered in order to apply the alternate marking methodology in any ci= rcumstances. So we invite all of you to read our document and share your comments. Best Regards, Giuseppe, Mauro, Amedeo and Riccardo -----Messaggio originale----- Da: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Inviato: gioved=EC 29 giugno 2017 14:49 A: Riccardo Sisto; Fioccola Giuseppe; Cociglio Mauro; Amedeo Sapio Oggetto: New Version Notification for draft-fioccola-ippm-multipoint-alt-mar= k-00.txt A new version of I-D, draft-fioccola-ippm-multipoint-alt-mark-00.txt has been successfully submitted by Giuseppe Fioccola and posted to the IETF= repository. Name: draft-fioccola-ippm-multipoint-alt-mark Revision: 00 Title: Multipoint Alternate Marking method for passive a= nd hybrid performance monitoring Document date: 2017-06-29 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-fioccola-ippm-mul= tipoint-alt-mark-00.txt Status: https://datatracker.ietf.org/doc/draft-fioccola-ippm-multipo= int-alt-mark/ Htmlized: https://tools.ietf.org/html/draft-fioccola-ippm-multipoint-a= lt-mark-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-fioccola-ippm-mu= ltipoint-alt-mark-00 Abstract: The Alternate Marking method, as presented in [I-D.ietf-ippm-alt-mark], can be applied only to point-to-point flows because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document aims to generalize and expand this methodology to measure any kind of unicast flows, whose packets can follow several different paths in the network, in wider terms a multipoint-to-multipoint network. For this reason the technique here described is called Multipoint Alternate Marking. 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. The IETF Secretariat Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. --_000_93108cfef41c4cfb944883423a2a1766TELMBXB02RM001telecomit_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable

Hi IPPMers,=

Following the progress of the= draft-ietf-ippm-alt-mark, that describes the alternate marking technology i= n a point-to-point scenario, we introduce this new draft, that is a generali= zation of the methodology in order to measure any kind of unicast flow in a multipoint-to-multipoint scenario.=

The -00 version is focused on= the network clustering technique, that has to be considered in order to app= ly the alternate marking methodology in any circumstances.=

 

So we invite all of you to re= ad our document and share your comments.

 

Best Regards,

 

Giuseppe, Mauro, Amedeo and R= iccardo

 

-----Messa= ggio originale-----
Da: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Inviato: gioved=EC 29 giugno 2017 14:49
A: Riccardo Sisto; Fioccola Giuseppe; Cociglio Mauro; Amedeo Sapio
Oggetto: New Version Notification for draft-fioccola-ippm-multipoint-alt-mar= k-00.txt

 

 

A new version of I-D, draft-f= ioccola-ippm-multipoint-alt-mark-00.txt

has been successfully submitt= ed by Giuseppe Fioccola and posted to the IETF repository.=

 

Name:    =             &nbs= p; draft-fioccola-ippm-multipoint-alt-mark

Revision:   &n= bsp;         00

Title:    = ;            &nb= sp;    Multipoint Alternate Marking method for passive and hy= brid performance monitoring

Document date:  &nb= sp;           2017-06-29

Group:    = ;             In= dividual Submission

Pages:    = ;            &nb= sp; 12

URL:    &= nbsp;       https://www.ie= tf.org/internet-drafts/draft-fioccola-ippm-multipoint-alt-mark-00.txt=

Status:   &nbs= p;     https://datatracker.ietf.org/doc/draft-= fioccola-ippm-multipoint-alt-mark/

Htmlized:   &n= bsp;   https://tools.ietf.org/html/draft-fioccola-ippm-mult= ipoint-alt-mark-00

Htmlized:   &n= bsp;   https://datatracker.ietf.org/doc/html/draf= t-fioccola-ippm-multipoint-alt-mark-00<= /o:p>

 

 

Abstract:

   The Alternate Ma= rking method, as presented in

   [I-D.ietf-ippm-a= lt-mark], can be applied only to point-to-point flows

   because it assum= es that all the packets of the flow measured on one

   node are measure= d again by a single second node.  This document aims<= /p>

   to generalize an= d expand this methodology to measure any kind of

   unicast flows, w= hose packets can follow several different paths in

   the network, in= wider terms a multipoint-to-multipoint network.  For=

   this reason the= technique here described is called Multipoint

   Alternate Markin= g.

 

 

     = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;

 

 

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.

 

The IETF Secretariat

 

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle= persone indicate. La diffusione, copia o qualsiasi altra azione derivante d= alla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a= bbiate ricevuto questo documento per errore siete cortesemente pregati di da= rne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.

This e-mail and any attachments is confidential and may contain privil= eged information intended for the addressee(s) only. Dissemination, copying,= printing or use by anybody else is unauthorised. If you are not the intende= d recipient, please delete this message and any attachments and advise the s= ender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessa= rio.
--_000_93108cfef41c4cfb944883423a2a1766TELMBXB02RM001telecomit_-- From nobody Thu Jun 29 09:24:11 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F11513149A; Thu, 29 Jun 2017 09:24:10 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 sTPD1fcHpC-c; Thu, 29 Jun 2017 09:24:07 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 DB5B2131495; Thu, 29 Jun 2017 09:24:07 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v5TGFKok030779; Thu, 29 Jun 2017 12:24:02 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by mx0a-00191d01.pphosted.com with ESMTP id 2bcyfbhqge-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Jun 2017 12:24:02 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v5TGO1xv042603; Thu, 29 Jun 2017 11:24:01 -0500 Received: from dalint01.pst.cso.att.com (dalint01.pst.cso.att.com [135.31.133.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v5TGNxw7042532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Jun 2017 11:23:59 -0500 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by dalint01.pst.cso.att.com (RSA Interceptor); Thu, 29 Jun 2017 16:23:45 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v5TGNiAY030934; Thu, 29 Jun 2017 11:23:44 -0500 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v5TGNaD6030471; Thu, 29 Jun 2017 11:23:36 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id A79D4E08D5; Thu, 29 Jun 2017 12:23:35 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Thu, 29 Jun 2017 12:23:35 -0400 From: "MORTON, ALFRED C (AL)" To: "Ruediger.Geib@telekom.de" CC: "ippm-chairs@ietf.org" , "ippm@ietf.org" Thread-Topic: New draft on Advanced Route Metrics and Measurements Thread-Index: AdLwc1WSB70hnm82ToejYJQjP5zb/wASQgLAAArS7XA= Date: Thu, 29 Jun 2017 16:23:35 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25FE8062@njmtexg5.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF25FE7B3E@njmtexg5.research.att.com> <03b0eab95a1f4c10930756248ace669a@HE101653.emea1.cds.t-internal.com> In-Reply-To: <03b0eab95a1f4c10930756248ace669a@HE101653.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.178.187.36] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-29_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706290265 Archived-At: Subject: Re: [ippm] New draft on Advanced Route Metrics and Measurements X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 16:24:10 -0000 Hi R=FCdiger, Thanks for sharing your comments on the ippm-list. Ignacio, Joachim and I appreciate your timely and helpful review! You've started the To Do list for the next rev. please see more replies below, Al > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Thursday, June 29, 2017 6:05 AM > To: MORTON, ALFRED C (AL) > Cc: ippm-chairs@ietf.org; ippm@ietf.org > Subject: AW: New draft on Advanced Route Metrics and Measurements >=20 > Hi Al, >=20 > I briefly read the draft. Reliably tracing one or more IP paths is a > reasonable aim. Some comments: > - this is a standards track doc containing no requirement language. > - if this remains a standards track doc, the guidance on how to code > packets must be well defined. > For the time being, a reader has an impression what to do, and an > expert may indeed do so. [ACM]=20 Yes. We have only taken the step to define new parameters, metrics, methods= , and analysis as *concepts* so far, without requirements language. If folks agree that the descriptions are clear enough to proceed, we'll adopt the RFC 2119 terms and move toward tighter specifications. > - the draft does not differentiate between equal paths along different > routers and equal paths > between the same pair of routers (i.e. multiple parallel links). I > think, the latter can't be detected. > This should be clarified. [ACM]=20 The concept of a *discoverable* host is at the root of your comment. We haven't provided a formal definition for this term yet and it needs some further discussion, but it will probably include the=20 relevant requirements for hosts and routers (RFC 1122), and some additional requirements that apply for hybrid methods,=20 at least. Specific to your question: If a pair of discovered hosts identify two different IP addresses, then they will appear to be different hosts. If a pair of discovered hosts identify two different IP addresses, and the IP addresses resolve to the same host name (in the DNS), then they will appear to be the same hosts. If a discovered host always replies using the same IP address, regardless of the interface a packet arrives on, then multiple parallel links cannot be detected at the IP layer. If parallel links between routers are aggregated below the IP layer, IOW, all links share the same pair of IP addresses, then the existence of these parallel links can't be detected at IP layer. > - It is not clear how in-band-oam can be combined or used to complete > the advanced route metrics. > Especially the multi-domain and single-domain measurement should be > decoupled more > clearly. [ACM]=20 Thanks, I think we all need to better understand what we'll be able to do with the new hybrid methods (we are calling both the "new-ish"=20 active methods we describe, and new hybrid methods, "advanced" methods). It seems likely that combinations of route information derived from active and hybrid methods will provide additional information. This is particularly true if hosts inside an in-situ domain are=20 "not discoverable" except when using Hybrid Type I methods. > - If the authors think that the guidance=20 > "change several fields to keep the checksum of different > packets identical" doesn't require any security discussion, the > authors should say so in the > security section. [ACM]=20 Thanks for that. We only have the most basic security considerations right now, which only address active and passive methods.=20 There will be *new* security considerations for Hybrid Type I=20 methods, and we certainly will reference them when available or add them in the text. We may also need to explain that the process you quoted above is only part of the active methods, and it is executed at the Source host before sending a packet. Perhaps that is sufficient explanation, unless I'm overlooking something? >=20 > Regards, >=20 > Ruediger >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: ippm [mailto:ippm-bounces@ietf.org] Im Auftrag von MORTON, ALFRED C > (AL) > Gesendet: Donnerstag, 29. Juni 2017 03:10 > An: ippm@ietf.org > Cc: ippm-chairs@ietf.org > Betreff: [ippm] New draft on Advanced Route Metrics and Measurements >=20 > IPPM, >=20 > Back at IETF-95 in Buenos Aires, the IPPM WG wanted to see some > "traceroute" support in the Registry, but we didn't even have a metric > to reference. > Many methods were available, producing differing results. > Now, with in-situ OAM, it's possible that there will be more advanced > methods of measurement than ever before. > There are also some interesting RTD analysis possibilities which we > describe. We've been working on this draft in fits and starts since > meeting in "BA". >=20 > We invite IPPM'ers to read our draft and share your reactions and > comments here. >=20 > thanks and regards, > Ignacio, Joachim, and Al >=20 > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Advanced Unidirectional Route Assessment > Authors : Jos=E9 Ignacio Alvarez-Hamelin > Al Morton > Joachim Fabini > Filename : draft-amf-ippm-route-00.txt > Pages : 17 > Date : 2017-06-28 >=20 > Abstract: > This memo introduces an advanced unidirectional route assessment > metric and associated measurement methodology, based on the IP > Performance Metrics (IPPM) Framework RFC 2330. This memo updates RFC > 2330 in the areas of path-related terminology and path description, > primarily to include the possibility of parallel subpaths. >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_draft-2Damf-2Dippm-2Droute-2D00&d=3DDwIFAw&c=3DLF= YZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DV2yRRSNIWQVXxuQy- > ZLI3oPhDjf_iSxw69Z_OiUManw&s=3DN99w_k6mo_iuyB- > u3Jpp3jdMihOJNyOzJnfNzbhGQzQ&e=3D >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwIFAw&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DV2yRRSNIWQVXxuQy- > ZLI3oPhDjf_iSxw69Z_OiUManw&s=3DLIgwFuKTWJdv9lbvno2SxHkMfMvFpFYRd5P9AQsXYO= s > &e=3D From nobody Thu Jun 29 12:12:47 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E0212E957; Thu, 29 Jun 2017 12:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VH-hY-Ji5GxP; Thu, 29 Jun 2017 12:12:44 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BE1126DEE; Thu, 29 Jun 2017 12:12:44 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id p21so84508515qke.3; Thu, 29 Jun 2017 12:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=ehMJTaiLdlBGjY/fsECsGraOvwc8iMtYEpiZwm9G5UQ=; b=tD1003/eCNjfEwIvllJnaxPS9mlZ240D0phmjo9nmKNE4LTaSDsv5nt2by7yIJYm1u ++72qoD5qpOoTdZJmOG/niBB6G5wOzjvI6eguHglc2v5218igJ5jWXYqdceE5WUB/T9g WGpAvlXnI19YAFI9tTfWGQwv1niEkCaRmTG8tnrjOSVczhovQStuG1wWxHnin7yzDAqU qbdlr6a6XudurgdxIZfKxKzbIRP3PR5KKoh9s50F4aU8JfBN0R5HWPsLPZZ3UiW9UZKZ vA/XvTeoo9V7EGix2HkXmbxFcpybIL9ffoN5O2N0BlJ5t9hpkmEhe7AJ/nwMI+zB6SqY Ynlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ehMJTaiLdlBGjY/fsECsGraOvwc8iMtYEpiZwm9G5UQ=; b=uOj7zP2GQyygLqwyBJUpqyUoYW7trnIeSSKNtMKeYJQPP96KRsNYImjnOnq82wPK81 WgynCwAS7Na052w192htn2oo7j5axnFKLzD3sOMPGVqPrkfbKD+xJ3qw28WoJobj53j/ qHBAV5q6/7Web+AUiB3jGslA+3wTR+JiRbDsdzWhQ5AgONJIvRZX85tIMLZmiPQ2c4vY FWby6VoMDWb1RWdiuLlVUD1jYgYK4hPVUMeedTdZ2lZRsheR72LHShhKOOSOqItAOY9Q CHhihZStBwau7QB3lNqqKaAPdjg3kWNOc2C1cezIg/T4R5qCdc6iizrLE5wi3j8IbZq4 P+vA== X-Gm-Message-State: AKS2vOwP6yl13AWuTZRGSPkdDVZL4JAKiq3/rcaS5eDuuaZdERLAryCj Vp0g4oodpaBqkCQqqLfHi/ahvt5t0gqmGMM= X-Received: by 10.55.36.141 with SMTP id k13mr21855366qkk.64.1498763563098; Thu, 29 Jun 2017 12:12:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.168 with HTTP; Thu, 29 Jun 2017 12:12:42 -0700 (PDT) From: Greg Mirsky Date: Thu, 29 Jun 2017 12:12:42 -0700 Message-ID: To: IPPM Chairs Cc: "ippm@ietf.org" Content-Type: multipart/alternative; boundary="001a1143219cc7e92005531e155d" Archived-At: Subject: [ippm] Presentation slots requests for Prague X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 19:12:45 -0000 --001a1143219cc7e92005531e155d Content-Type: text/plain; charset="UTF-8" Dear Brian and Bill, I'd like to ask for presentation slots at IPPM WG meeting in Prague: - draft-mirsky-ippm-twamp-refl-registered-port - presenter Greg Mirsky - draft-mirsky-ippm-twamp-light-yang - presenter Greg Mirsky I'll submit presentation slides by Sunday, July 16. Thank you for your kind consideration. Regards, Greg --001a1143219cc7e92005531e155d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Brian and Bill,
I'd like to ask for presentat= ion slots at IPPM WG meeting in Prague:
  • draft-mirsky-ippm-twamp-refl-registered-port - presenter Greg Mirsky
  • draft-mirsky-ippm-twamp-light-yang - presenter Greg Mirsky
    <= /span>
I'll submit presentation slides by Sunday, July 16.

<= /font>
Thank you for your kind consideration.

Regards,
Greg
--001a1143219cc7e92005531e155d-- From nobody Thu Jun 29 13:31:44 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83C412EB04; Thu, 29 Jun 2017 13:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 EgFlNCRcpb-M; Thu, 29 Jun 2017 13:31:41 -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 98B0F126DC2; Thu, 29 Jun 2017 13:31:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQB61236; Thu, 29 Jun 2017 20:31:38 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 29 Jun 2017 21:31:37 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000; Thu, 29 Jun 2017 13:31:34 -0700 From: Haoyu song To: IPPM Chairs CC: "ippm@ietf.org" Thread-Topic: Presentation slots requests for Prague Thread-Index: AdLxFrIF19KJtOGLRtCgUQEDsaCy3w== Date: Thu, 29 Jun 2017 20:31:34 +0000 Message-ID: <78A2745BE9B57D4F9D27F86655EB87F925959102@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.164] Content-Type: multipart/alternative; boundary="_000_78A2745BE9B57D4F9D27F86655EB87F925959102SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.595563AA.01F7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 91626ef8c1cbe38e98e1acd3a9ac3d4b Archived-At: Subject: [ippm] Presentation slots requests for Prague X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 20:31:42 -0000 --_000_78A2745BE9B57D4F9D27F86655EB87F925959102SJCEML702CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBJUFBNIGNoYWlycywNCg0KSeKAmWQgbGlrZSB0byBhc2sgZm9yIHByZXNlbnRhdGlvbiBz bG90IGZvciB0aGUgZm9sbG93aW5nIGRyYWZ0Og0KDQpkcmFmdC1zb25nLWlwcG0taW9hbS1zY2Fs YWJpbGl0eSDigJMgcHJlc2VudGVyIEhhb3l1IFNvbmcNCg0KVGhhbmsgeW91IGZvciBjb25zaWRl cmF0aW9uLg0KDQpCZXN0LA0KSGFveXUNCg0K --_000_78A2745BE9B57D4F9D27F86655EB87F925959102SJCEML702CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY0MDc3Mjk3MzsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTEyMDkxNzYxMDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+RGVhciBJUFBNIGNoYWlycyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPknigJlkIGxpa2UgdG8gYXNrIGZvciBwcmVzZW50YXRp b24gc2xvdCBmb3IgdGhlIGZvbGxvd2luZyBkcmFmdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPmRyYWZ0LXNvbmctaXBwbS1pb2FtLXNjYWxhYmlsaXR5IOKAkyBw cmVzZW50ZXIgSGFveXUgU29uZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmsgeW91IGZvciBjb25zaWRl cmF0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5IYW95dTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_78A2745BE9B57D4F9D27F86655EB87F925959102SJCEML702CHMchi_-- From nobody Thu Jun 29 19:12:50 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD8E12EAEE; Thu, 29 Jun 2017 19:12:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149878876215.4618.2372995979161837115@ietfa.amsl.com> Date: Thu, 29 Jun 2017 19:12:42 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-model-based-metrics-11.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 02:12:42 -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 of the IETF. Title : Model Based Metrics for Bulk Transport Capacity Authors : Matt Mathis Al Morton Filename : draft-ietf-ippm-model-based-metrics-11.txt Pages : 54 Date : 2017-06-29 Abstract: We introduce a new class of Model Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance. Model Based Metrics rely on peer-reviewed mathematical models to specify a Targeted Suite of IP Diagnostic tests, designed to assess whether common transport protocols can be expected to meet a predetermined Target Transport Performance over an Internet path. For Bulk Transport Capacity IP diagnostics are built using test streams and statistical criteria for evaluating the packet transfer that mimic TCP over the complete path. The temporal structure of the test stream (bursts, etc) mimic TCP or other transport protocol carrying bulk data over a long path. However they are constructed to be independent of the details of the subpath under test, end systems or applications. Likewise the success criteria evaluates the packet transfer statistics of the subpath against criteria determined by protocol performance models applied to the Target Transport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems or application. Model Based Metrics exhibit several important new properties not present in other Bulk Transport Capacity Metrics, including the ability to reason about concatenated or overlapping subpaths. The results are vantage independent which is critical for supporting independent validation of tests by comparing results from multiple measurement points. This document provides a framework for designing suites of IP diagnostic tests that are tailored to confirming that infrastructure can meet the predetermined Target Transport Performance. It does not fully specify the IP diagnostics tests needed to assure any specific target performance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-model-based-metrics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-model-based-metrics-11 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-model-based-metrics-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-model-based-metrics-11 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 Jun 29 21:26:09 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C590127599 for ; Thu, 29 Jun 2017 21:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ePqcN-L1XkRK for ; Thu, 29 Jun 2017 21:26:06 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01AD1274D2 for ; Thu, 29 Jun 2017 21:26:05 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id b184so33422213wme.1 for ; Thu, 29 Jun 2017 21:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PHGza7245r8Tr66LRZoNu8U7ZM0/ow+ExzjWFL0TAQo=; b=eR47MpQnHBjSXLkgf5KdAuogbHK/ckXG5amL/laY7x9LGDvE8JxzDEPwow+H2BOshu 92UKAfG4DESebHqxf/Tif60k6h2cxT4dOJC1ydBIEcfbk45M6mquC+6Po/5qxS9tDEPR 7QiAaMWmzISHbOXcun3ox6+ht+U26O5dbPu17Y9EFk/8RlQFj85LeBi4MOgnwjT8r0/8 p1Hhl7HjynVOeBE2c6vJgRflNU8YG1ifF7K9+m9s3gLEV5xz8xMbtp9ltkRShxoW8qY4 PW+PCngel5W2hDQ4VOvRZ6/hzv35GAsRJk9+O+DCAGYuL67yebJ1l6cBwG/08zqlbYNA 9mYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PHGza7245r8Tr66LRZoNu8U7ZM0/ow+ExzjWFL0TAQo=; b=L5cmrxvP6eTrVsrjeDKLqkYyFaVdb1EBZhGMdiYUCSdng+DYMOm9Ji5RTVpmlegrue O2Z3xIahyxSR5KT4w/RtDwcfr1E+ttDBiQ69DCGIz8G1Mxfi2iPL4cWXbfC0BahdNNXW KLdhdpHWE7MOLhV5Eg6mdPeATYIR6uskbvbbEEBg14tv14/oMQBFSZAugsAfMlrOe7wx aZ8gVylsDzY5EgPBjLUWCDpuqsvGk5s8zzYj1OfwbEwTG96DsdyxWthlnQkEneoznMNf yocU21D8Mm9e5uUA1EwITf6Q4fnUMmTyWvH5CQSJ2vSez/MrYTArhow86GxrlHaEiEoo 2GBA== X-Gm-Message-State: AKS2vOx6aepcrfTzDk7Ms7WOcfvvacF24d3Z4uR05nTVa5VzGFaMJVBF oaraGZ77nou2ibVOr14d0xtjeo+mEA== X-Received: by 10.80.165.164 with SMTP id a33mr3817004edc.53.1498796764373; Thu, 29 Jun 2017 21:26:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.170.19 with HTTP; Thu, 29 Jun 2017 21:26:04 -0700 (PDT) In-Reply-To: <8652552cd3ef416fb4f4e1a088ead8cd@IL-EXCH01.marvell.com> References: <8652552cd3ef416fb4f4e1a088ead8cd@IL-EXCH01.marvell.com> From: Tal Mizrahi Date: Fri, 30 Jun 2017 07:26:04 +0300 Message-ID: To: ippm@ietf.org Content-Type: multipart/alternative; boundary="f403045c2806bb2968055325d021" Archived-At: Subject: [ippm] Fwd: New Version Notification for draft-mizrahi-ippm-multiplexed-alternate-marking-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 04:26:08 -0000 --f403045c2806bb2968055325d021 Content-Type: text/plain; charset="UTF-8" Hi, We have made a major revision of the draft. Its scope is now wider, and hopefully more useful to the reader - please see the abstract below for further details. Following this major revision, we would highly appreciate any comments, and especially any feedback regarding whether the draft is of interest to the WG. Thanks, Tal. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Friday, June 30, 2017 7:08 AM To: Giuseppe Fioccola; Tal Mizrahi; Gregory Mirsky; Carmi Arad; Mauro Cociglio; Greg Mirsky; Mach Chen; Mach Chen (Guoyi); Lianshu Zheng Subject: [EXT] New Version Notification for draft-mizrahi-ippm- multiplexed-alternate-marking-02.txt External Email ---------------------------------------------------------------------- A new version of I-D, draft-mizrahi-ippm-multiplexed-alternate-marking- 02.txt has been successfully submitted by Tal Mizrahi and posted to the IETF repository. Name: draft-mizrahi-ippm-multiplexed-alternate-marking Revision: 02 Title: Compact Alternate Marking Methods for Passive Performance Monitoring Document date: 2017-06-29 Group: Individual Submission Pages: 21 URL: https://www.ietf.org/internet-drafts/draft-mizrahi-ippm- multiplexed-alternate-marking-02.txt Status: https://datatracker.ietf.org/doc/draft-mizrahi-ippm- multiplexed-alternate-marking/ Htmlized: https://tools.ietf.org/html/draft-mizrahi-ippm- multiplexed-alternate-marking-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-mizrahi-ippm- multiplexed-alternate-marking-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-mizrahi-ippm- multiplexed-alternate-marking-02 Abstract: This memo introduces new alternate marking methods that require a compact overhead of either a single bit per packet, or zero bits per packet. This memo also presents a summary of alternate marking methods, and discusses the tradeoffs among them. The target audience of this document is network protocol designers; this document is intended to help protocol designers choose the best alternate marking method(s) based on the protocol's constraints and requirements. 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. The IETF Secretariat --f403045c2806bb2968055325d021 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We have made a major rev= ision of the draft. Its scope is now wider, and hopefully more useful to th= e reader - please see the abstract below for further details.
Following this major revision, we would highly appreciate any c= omments, and especially any feedback regarding whether the draft is of inte= rest to the WG.

Thanks,
Tal.
<= br>


-----Original Messag= e-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Friday, June 30, 2017 7:08 AM
To: Giuseppe Fioccola; Tal Mizrahi; Gregory Mirsky; Carmi Arad; Mauro Cocig= lio; Greg Mirsky; Mach Chen; Mach Chen (Guoyi); Lianshu Zheng
Subject: [EXT] New Version Notification for draft-mizrahi-ippm-multipl= exed-alternate-marking-02.txt

External Email

-----------------------------------------------------------------= -----

A new version of I-D, draft-mizrahi-ippm-multiplexed-alternate-marking= -02.txt
has been successfully submitted by Tal Mizrahi and posted to the IETF repos= itory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mizrahi-ippm-multi= plexed-alternate-marking
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Compact Alternate Marking Methods = for Passive Performance Monitoring
Document date:=C2=A0 2017-06-29
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 21
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-dr= afts/draft-mizrahi-ippm-multiplexed-alternate-marking-02.txt<= br> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mizrahi-= ippm-multiplexed-alternate-marking/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mizrahi-ippm-mul= tiplexed-alternate-marking-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-m= izrahi-ippm-multiplexed-alternate-marking-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3D= draft-mizrahi-ippm-multiplexed-alternate-marking-02

Abstract:
=C2=A0 =C2=A0This memo introduces new alternate marking methods that requir= e a
=C2=A0 =C2=A0compact overhead of either a single bit per packet, or zero bi= ts per
=C2=A0 =C2=A0packet.=C2=A0 This memo also presents a summary of alternate m= arking
=C2=A0 =C2=A0methods, and discusses the tradeoffs among them.=C2=A0 The tar= get audience
=C2=A0 =C2=A0of this document is network protocol designers; this document = is
=C2=A0 =C2=A0intended to help protocol designers choose the best alternate = marking
=C2=A0 =C2=A0method(s) based on the protocol's constraints and requirem= ents.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--f403045c2806bb2968055325d021-- From nobody Thu Jun 29 23:24:11 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1AB1200CF for ; Thu, 29 Jun 2017 23:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 QEBt__G-PiG5 for ; Thu, 29 Jun 2017 23:24:07 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D537128854 for ; Thu, 29 Jun 2017 23:24:07 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5611B340DAE for ; Fri, 30 Jun 2017 08:24:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.19959); Fri, 30 Jun 2017 08:24:05 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Fri, 30 Jun 2017 08:24:05 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 22347990 for ippm@ietf.org; Fri, 30 Jun 2017 08:24:05 +0200 From: "Brian Trammell (IETF)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_06B8A123-5214-441B-BBBA-06B520DB5198"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 30 Jun 2017 08:24:04 +0200 Message-Id: <49ECD161-A593-48FE-A61C-CFCB78946C88@trammell.ch> To: IETF IPPM WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [ippm] Shepherding draft-ietf-ippm-alt-mark-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 06:24:10 -0000 --Apple-Mail=_06B8A123-5214-441B-BBBA-06B520DB5198 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, In accordance with an [IESG = statement](https://www.ietf.org/iesg/statement/document-shepherds.html) = that we've been slow to pay attention to here in IPPM, we're looking for = a volunteer to shepherd draft-ietf-ippm-alt-mark-05 through the = publication process. Ideally, this would be a non-author who has reviewed the document. The = document shepherd role is described in = [RFC4858](https://tools.ietf.org/html/rfc4858), but the main = responsibility is the document shepherd writeup (section 3.1) Please reply to ippm-chairs@tools.ietf.org to volunteer. In the future, = we'll start the process of assigning a shepherd to a document much = earlier, with WG adoption. Thanks, cheers, Brian --Apple-Mail=_06B8A123-5214-441B-BBBA-06B520DB5198 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 iQIcBAEBCgAGBQJZVe6EAAoJEIoSt78L6kajQtwQAMP38F16/rzbi8/BYtIfJik4 S6FOA/h+o+XyolqXOpmS5K05VhznIsUidojchnRHovrnphEwUD/+1QUW6aRORTC/ 3OkGZoOzDBjivbsHD/RLbxmj97zmgq4gwYmA0sCPWNsE5CaEnUsuYwfIBURZt5PE nxcRNSxb06UZsqSneFTAZWdrIQ7LiF9PPjgEG9i+3PM6Gxa5vpj2K7y0xjZgWJH+ 0demUso8H7T+i3ziMbUa7HTmMEE98jZRwFm2gNOXydcJDZsp0fxyO+JcHiEQRGNW Ricb+Z9prExbPg6BLcycZY7OoKzdSEyGR9FcDhmCwUyMNeD939yLEwCJ/TeOxTv8 S1H+FeR+OTSz5NeWl/YjFn1eNmBeinyXOvxl/IX7sShTjd5nVciqY6e0aqHzgtCe C/j0hf3cSiHF9WwO5VUA3i1ql20V7yNGcJ/bwQOrSJjLBTlNvDdK+LtALRFbJxlT DKKzLa0FOavGPmQyczAXtTBZg91y9JFiVmhJ+OqU52dAhvkH9Zf9qHd5EGpZOCQ8 vhUsC4KoIyvCu/70W3ZX8t49DjPMOs64X6G7Uqxv0/5Nhe0x3N9Nhym91nMYgrnG xH82kmOR2uWjtryiHlPELobNny9mf7t31REvtWzYIHRM8TY4wu47tUst2tA+f/mG ZApiQYhM/g0gYzNMwhL+ =4PKL -----END PGP SIGNATURE----- --Apple-Mail=_06B8A123-5214-441B-BBBA-06B520DB5198-- From nobody Thu Jun 29 23:26:07 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41CF128854 for ; Thu, 29 Jun 2017 23:26: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 autolearn_force=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 tgrYwNauBPll for ; Thu, 29 Jun 2017 23:26:03 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BE1127B52 for ; Thu, 29 Jun 2017 23:26:03 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 57497340DB2 for ; Fri, 30 Jun 2017 08:26:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.19406); Fri, 30 Jun 2017 08:26:02 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Fri, 30 Jun 2017 08:26:02 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 22348150 for ippm@ietf.org; Fri, 30 Jun 2017 08:26:02 +0200 From: "Brian Trammell (IETF)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_DA7DA175-3233-4A02-BD41-5E1D2DE76789"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 30 Jun 2017 08:26:01 +0200 Message-Id: To: IETF IPPM WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [ippm] Shepherding draft-ietf-ippm-twamp-yang X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 06:26:06 -0000 --Apple-Mail=_DA7DA175-3233-4A02-BD41-5E1D2DE76789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We're looking for a volunteer to shepherd draft-ietf-ippm-twamp-yang, on = which we intend to start WGLC in Prague, through the publication = process. Ideally, this would be a non-author who has reviewed the document. The = document shepherd role is described in = [RFC4858](https://tools.ietf.org/html/rfc4858) as amended by an [IESG = statement](https://www.ietf.org/iesg/statement/document-shepherds.html). Please reply to ippm-chairs@tools.ietf.org to volunteer. Thanks, cheers, Brian --Apple-Mail=_DA7DA175-3233-4A02-BD41-5E1D2DE76789 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 iQIcBAEBCgAGBQJZVe75AAoJEIoSt78L6kajOU0P/05oWmOZgHEycIh0cegVaNee 35KKrW+ZmtjkXj0zM00bh6fHz8iKMMIYOR29PeCp3oWZWmZaAENR7NduCMtZZa8T bRE5qZbVHgYuVd+DZpVB/hzkCTimxsHd0riugoeZ/CYoUjJI/wgtMLyHc0awVgt5 FEynwRYKmqwYb5S/qcf+dVbLPIiCRfCcA/TfDeTrUjPPlVR4AjceUQ0jk5n/uCSS B+CKWKOfVhqeeV1d5c6V747NmYC+HCo0HVhdDbOc4iWpeX4gWrLhoUEGLz3qDd+P gxBNzTRaTDUDEdsByJjulhs6kbyVzd1ALlHAj1nO7qFsMWZY+S46A246hrg3hwaP ZFFDfGB1Jw7RO7FnsIcgwwc1Wq0mhVaXc/8cx+Xbs9Rs0y0Gw4XmwpO0m+boccMJ 1fq6FxoJ3A7x/4AyfSJLaRU26NN+0TdA76YSiwVj1Fbd1Q4GyYTo6wdlt/unLjMS ANDDlbIc2GEfutzYxpvNwnKZ6NY6tos5YimkR4114s1geXCMFG3uPjEyd+zPnoqC fZqk1auTmtrfb0+XegtFbFFNWe7IViYcm4onwkYuheSF1EK7F4DGmmZ/fumGHEZO 4TFUHklvm97yll8nSLHaIpYxWUdbFr69L56TV2WL3Yfs+FqDeW0JpCRX0uY88n6s zeTBuLeX+cfDG9EnRc5D =R5HY -----END PGP SIGNATURE----- --Apple-Mail=_DA7DA175-3233-4A02-BD41-5E1D2DE76789-- From nobody Thu Jun 29 23:28:17 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB5B128854 for ; Thu, 29 Jun 2017 23:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 9QNcqXf4OBUK for ; Thu, 29 Jun 2017 23:28:13 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423D8127444 for ; Thu, 29 Jun 2017 23:28:13 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 10F8C340DB2 for ; Fri, 30 Jun 2017 08:28:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.19959); Fri, 30 Jun 2017 08:28:12 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Fri, 30 Jun 2017 08:28:12 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 22348386 for ippm@ietf.org; Fri, 30 Jun 2017 08:28:11 +0200 From: "Brian Trammell (IETF)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_78AD4856-95DE-44C2-BEA9-FADE59731529"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 30 Jun 2017 08:28:11 +0200 Message-Id: <5436EBCF-4270-404A-A20C-1C77CE1B19DC@trammell.ch> To: IETF IPPM WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [ippm] Shepherding draft-ietf-ippm-2330-ipv6 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 06:28:15 -0000 --Apple-Mail=_78AD4856-95DE-44C2-BEA9-FADE59731529 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We're looking for a volunteer to shepherd draft-ietf-ippm-2330-ipv6, = through the publication process. IIRC this document is waiting on 6man, = so WGLC won't happen soon (authors, please correct me on this). Ideally, this would be a non-author who has reviewed the document. The = document shepherd role is described in = [RFC4858](https://tools.ietf.org/html/rfc4858) as amended by an [IESG = statement](https://www.ietf.org/iesg/statement/document-shepherds.html). Please reply to ippm-chairs@tools.ietf.org to volunteer. Thanks, cheers, Brian --Apple-Mail=_78AD4856-95DE-44C2-BEA9-FADE59731529 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 iQIcBAEBCgAGBQJZVe97AAoJEIoSt78L6kajFEMP/0km6ePvJw+shFdygnemgL0S kwpCimSH5k7sjkYvT2W95GGCC41TjBeIscW3+d9iYWKPoIvuLGbJF/730kb+CyJg pNz8e5lvQNKR2GT+GFby0+Zmfq0WvQK5rnR8FAhXe6tIGlfmiK+umzO/HL2QeSwy NAHqgWakP7ZwYzamLdy/9KYJ8VYRifEhecMuc/+ARhJadcps9LN2OzIPOlEoWzrG Y15p6TNkTRma3ppLGvWuEK+HjzwxQugghFMtFNi7VtGLTmSWyo3oth3ibmD83mr8 BpmF3DDwF1fQjW0ZFNUP0ltMJiwu9n0epDESAI1J18GwHFBRzN7/VbIOEXioLN86 elC89/qXnnjIvR9t+ftB+DAFsLdQ0RDTCxTwE6fe/0tkmEUGenuwFYSHyM0+U5Os A/c65jq9VG/EqI/Ezht0Zc1kZ3HrabA9eZW0cshA6hwAmmasFyfFahkMgEelNnf4 RU0BrNo+z90Kz2AxjwX3Ju3tvf98tBaaPLh6E107yFHvjfax8E48qnPujsLwFhI5 0XylrN0TrE5Wyu2ZJSC5GHB6tfuziK1P3JUCQ7QMbY/7eJZsQvqZr0bp27P5YGbk YI2A/GBGH5jvVVeWYeDf2lwgN86A1UA+227doZcivV3GF/dLgzz+a3GlkC4GuRs+ 9pzne0u6LvEmk14AXmM5 =jWHi -----END PGP SIGNATURE----- --Apple-Mail=_78AD4856-95DE-44C2-BEA9-FADE59731529-- From nobody Thu Jun 29 23:56:21 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8449126BF0; Thu, 29 Jun 2017 23:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 yEeKvguPNMuk; Thu, 29 Jun 2017 23:56:16 -0700 (PDT) Received: from MAILOUT31.telekom.de (MAILOUT31.telekom.de [80.149.113.193]) (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 BFADB129AB2; Thu, 29 Jun 2017 23:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1498805776; x=1530341776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2wbt2ISzJRykEYO+S+67tYqU0c8Qnje5qgVcXn9BQLQ=; b=31TW+pRmPcr9SpaoNFwixsD/8Ut608I+PmkpXnLr6lJGeCj/zEQQJS1O qTg3Z5EcD5HGMK6O3HWDq5xyWAZJGAvXvr97o6J617NjkzlU965kqByxf KG9cVGdclXO+v87NKv0BL1NgfXVMhIYIEUQUFClOEUa4F5ImxT5L7YJ1v 1zZjefwaTN40JB0FYnokoL0S7L2FQmDgz985lYtsNp5x5Zd32HkEdLgZa raFUn+eA59iA7+6raard6ZToXV0OPNDI7p/JCkW8THMTiPshNvpkBCu0i X0xUpx3D/ErJzzhJCcsFDqyiyYNz7OYZeBa2vgTy3Y7GbpS3B8wgMSrTs A==; Received: from q4de8ssaz61.gppng.telekom.de ([10.206.166.200]) by MAILOUT31.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jun 2017 08:56:12 +0200 X-IronPort-AV: E=Sophos;i="5.40,285,1496095200"; d="scan'208";a="1207028506" Received: from he101655.emea1.cds.t-internal.com ([10.134.226.17]) by q4de8ssazdv.gppng.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jun 2017 08:56:11 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101655.emea1.cds.t-internal.com (10.134.226.17) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 30 Jun 2017 08:56:11 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1263.000; Fri, 30 Jun 2017 08:56:11 +0200 From: To: CC: , Thread-Topic: New draft on Advanced Route Metrics and Measurements Thread-Index: AdLwc1WSB70hnm82ToejYJQjP5zb/wASQgLAAArS7XAAIVCwoA== Date: Fri, 30 Jun 2017 06:56:11 +0000 Message-ID: <33bddebdf9b046638c5e2d9f62089c60@HE101653.emea1.cds.t-internal.com> References: <4D7F4AD313D3FC43A053B309F97543CF25FE7B3E@njmtexg5.research.att.com> <03b0eab95a1f4c10930756248ace669a@HE101653.emea1.cds.t-internal.com> <4D7F4AD313D3FC43A053B309F97543CF25FE8062@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25FE8062@njmtexg5.research.att.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.163.239] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] New draft on Advanced Route Metrics and Measurements X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 06:56:20 -0000 Hi Al, thanks for your fast response. One more point while I'm reading. I'm not an= in-situ OAM expert, but as you add information to a packet, this should im= pact the checksum of that packet too. If this is true for in-situ-oam mecha= nisms (I don't know), and an identical end-to-end checksum field is part of= the Advanced Route Metrics functionality, the latter draft needs to discus= s application and limits of which method when. Your replies line out well what should be added (if the work is picked up b= y IPPM). Regards, R=FCdiger -----Urspr=FCngliche Nachricht----- Von: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Gesendet: Donnerstag, 29. Juni 2017 18:24 An: Geib, R=FCdiger Cc: ippm-chairs@ietf.org; ippm@ietf.org Betreff: RE: New draft on Advanced Route Metrics and Measurements Hi R=FCdiger, Thanks for sharing your comments on the ippm-list. Ignacio, Joachim and I appreciate your timely and helpful review! You've st= arted the To Do list for the next rev. please see more replies below, Al > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Thursday, June 29, 2017 6:05 AM > To: MORTON, ALFRED C (AL) > Cc: ippm-chairs@ietf.org; ippm@ietf.org > Subject: AW: New draft on Advanced Route Metrics and Measurements >=20 > Hi Al, >=20 > I briefly read the draft. Reliably tracing one or more IP paths is a=20 > reasonable aim. Some comments: > - this is a standards track doc containing no requirement language. > - if this remains a standards track doc, the guidance on how to code=20 > packets must be well defined. > For the time being, a reader has an impression what to do, and an=20 > expert may indeed do so. [ACM] Yes. We have only taken the step to define new parameters, metrics, methods= , and analysis as *concepts* so far, without requirements language. If folks agree that the descriptions are clear enough to proceed, we'll ado= pt the RFC 2119 terms and move toward tighter specifications. > - the draft does not differentiate between equal paths along different=20 > routers and equal paths > between the same pair of routers (i.e. multiple parallel links). I=20 > think, the latter can't be detected. > This should be clarified. [ACM] The concept of a *discoverable* host is at the root of your comment. We haven't provided a formal definition for this term yet and it needs some= further discussion, but it will probably include the relevant requirements= for hosts and routers (RFC 1122), and some additional requirements that ap= ply for hybrid methods, at least. Specific to your question: If a pair of discovered hosts identify two different IP addresses, then the= y will appear to be different hosts. If a pair of discovered hosts identify two different IP addresses, and the = IP addresses resolve to the same host name (in the DNS), then they will app= ear to be the same hosts. If a discovered host always replies using the same IP address, regardless o= f the interface a packet arrives on, then multiple parallel links cannot be= detected at the IP layer. If parallel links between routers are aggregated below the IP layer, IOW, a= ll links share the same pair of IP addresses, then the existence of these p= arallel links can't be detected at IP layer. > - It is not clear how in-band-oam can be combined or used to complete=20 > the advanced route metrics. > Especially the multi-domain and single-domain measurement should be=20 > decoupled more > clearly. [ACM] Thanks, I think we all need to better understand what we'll be able to do w= ith the new hybrid methods (we are calling both the "new-ish"=20 active methods we describe, and new hybrid methods, "advanced" methods). It seems likely that combinations of route information derived from active = and hybrid methods will provide additional information. This is particularly true if hosts inside an in-situ domain are "not discov= erable" except when using Hybrid Type I methods. > - If the authors think that the guidance "change several fields to=20 > keep the checksum of different > packets identical" doesn't require any security discussion, the=20 > authors should say so in the > security section. [ACM] Thanks for that. We only have the most basic security considerations right= now, which only address active and passive methods.=20 There will be *new* security considerations for Hybrid Type I methods, and = we certainly will reference them when available or add them in the text. We may also need to explain that the process you quoted above is only part = of the active methods, and it is executed at the Source host before sending= a packet. Perhaps that is sufficient explanation, unless I'm overlooking = something? >=20 > Regards, >=20 > Ruediger >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: ippm [mailto:ippm-bounces@ietf.org] Im Auftrag von MORTON, ALFRED=20 > C > (AL) > Gesendet: Donnerstag, 29. Juni 2017 03:10 > An: ippm@ietf.org > Cc: ippm-chairs@ietf.org > Betreff: [ippm] New draft on Advanced Route Metrics and Measurements >=20 > IPPM, >=20 > Back at IETF-95 in Buenos Aires, the IPPM WG wanted to see some=20 > "traceroute" support in the Registry, but we didn't even have a metric=20 > to reference. > Many methods were available, producing differing results. > Now, with in-situ OAM, it's possible that there will be more advanced=20 > methods of measurement than ever before. > There are also some interesting RTD analysis possibilities which we=20 > describe. We've been working on this draft in fits and starts since=20 > meeting in "BA". >=20 > We invite IPPM'ers to read our draft and share your reactions and=20 > comments here. >=20 > thanks and regards, > Ignacio, Joachim, and Al >=20 > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Advanced Unidirectional Route Assessment > Authors : Jos=E9 Ignacio Alvarez-Hamelin > Al Morton > Joachim Fabini > Filename : draft-amf-ippm-route-00.txt > Pages : 17 > Date : 2017-06-28 >=20 > Abstract: > This memo introduces an advanced unidirectional route assessment > metric and associated measurement methodology, based on the IP > Performance Metrics (IPPM) Framework RFC 2330. This memo updates RFC > 2330 in the areas of path-related terminology and path description, > primarily to include the possibility of parallel subpaths. >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_draft-2Damf-2Dippm-2Droute-2D00&d=3DDwIFAw&c=3DLF= Y > Z- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DV2yRRSNIWQVXxuQy- > ZLI3oPhDjf_iSxw69Z_OiUManw&s=3DN99w_k6mo_iuyB- > u3Jpp3jdMihOJNyOzJnfNzbhGQzQ&e=3D >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwIFAw&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DV2yRRSNIWQVXxuQy- > ZLI3oPhDjf_iSxw69Z_OiUManw&s=3DLIgwFuKTWJdv9lbvno2SxHkMfMvFpFYRd5P9AQsXY > Os > &e=3D From nobody Fri Jun 30 06:04:22 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8C1128990; Fri, 30 Jun 2017 06:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 OkB-GNLd7BG4; Fri, 30 Jun 2017 06:04:18 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 1DD7D1204DA; Fri, 30 Jun 2017 06:04:18 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5UCswi3015846; Fri, 30 Jun 2017 09:04:17 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049463.ppops.net-00191d01. with ESMTP id 2bdj3afsre-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Jun 2017 09:04:16 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v5UD4FUk125558; Fri, 30 Jun 2017 08:04:16 -0500 Received: from dalint03.pst.cso.att.com (dalint03.pst.cso.att.com [135.31.133.161]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v5UD4EtC125534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Jun 2017 08:04:14 -0500 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by dalint03.pst.cso.att.com (RSA Interceptor); Fri, 30 Jun 2017 13:03:56 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v5UD3tTR017335; Fri, 30 Jun 2017 08:03:56 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v5UD3mop016671; Fri, 30 Jun 2017 08:03:50 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id 38855F0490; Fri, 30 Jun 2017 09:03:48 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Fri, 30 Jun 2017 09:03:48 -0400 From: "MORTON, ALFRED C (AL)" To: "Ruediger.Geib@telekom.de" CC: "ippm-chairs@ietf.org" , "ippm@ietf.org" Thread-Topic: New draft on Advanced Route Metrics and Measurements Thread-Index: AdLwc1WSB70hnm82ToejYJQjP5zb/wASQgLAAArS7XAAIVCwoAAMnVDw Date: Fri, 30 Jun 2017 13:03:47 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25FE86FE@njmtexg5.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF25FE7B3E@njmtexg5.research.att.com> <03b0eab95a1f4c10930756248ace669a@HE101653.emea1.cds.t-internal.com> <4D7F4AD313D3FC43A053B309F97543CF25FE8062@njmtexg5.research.att.com> <33bddebdf9b046638c5e2d9f62089c60@HE101653.emea1.cds.t-internal.com> In-Reply-To: <33bddebdf9b046638c5e2d9f62089c60@HE101653.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.178.187.36] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706300206 Archived-At: Subject: Re: [ippm] New draft on Advanced Route Metrics and Measurements X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 13:04:21 -0000 Hi R=FCdiger,=20 > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Friday, June 30, 2017 2:56 AM > To: MORTON, ALFRED C (AL) > Cc: ippm-chairs@ietf.org; ippm@ietf.org > Subject: AW: New draft on Advanced Route Metrics and Measurements >=20 > Hi Al, >=20 > thanks for your fast response. One more point while I'm reading. I'm not > an in-situ OAM expert, but as you add information to a packet, this > should impact the checksum of that packet too.=20 [ACM]=20 Fortunately, the in-situ data fields are removed at the=20 domain boundary, so the remainder of the Internet path should see a single flow again (needs checking though). > If this is true for in- > situ-oam mechanisms (I don't know), and an identical end-to-end checksum > field is part of the Advanced Route Metrics functionality, the latter > draft needs to discuss application and limits of which method when. [ACM]=20 You've identified another important area for interaction among the "route" and "in-situ" author teams, and the WG. >=20 > Your replies line out well what should be added (if the work is picked > up by IPPM). [ACM]=20 Thanks again for your supportive comments, Al (for the co-authors) >=20 > Regards, >=20 > R=FCdiger >=20 > -----Urspr=FCngliche Nachricht----- > Von: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Gesendet: Donnerstag, 29. Juni 2017 18:24 > An: Geib, R=FCdiger > Cc: ippm-chairs@ietf.org; ippm@ietf.org > Betreff: RE: New draft on Advanced Route Metrics and Measurements >=20 > Hi R=FCdiger, >=20 > Thanks for sharing your comments on the ippm-list. > Ignacio, Joachim and I appreciate your timely and helpful review! You've > started the To Do list for the next rev. >=20 > please see more replies below, > Al >=20 > > -----Original Message----- > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > Sent: Thursday, June 29, 2017 6:05 AM > > To: MORTON, ALFRED C (AL) > > Cc: ippm-chairs@ietf.org; ippm@ietf.org > > Subject: AW: New draft on Advanced Route Metrics and Measurements > > > > Hi Al, > > > > I briefly read the draft. Reliably tracing one or more IP paths is a > > reasonable aim. Some comments: > > - this is a standards track doc containing no requirement language. > > - if this remains a standards track doc, the guidance on how to code > > packets must be well defined. > > For the time being, a reader has an impression what to do, and an > > expert may indeed do so. > [ACM] > Yes. We have only taken the step to define new parameters, metrics, > methods, and analysis as *concepts* so far, without requirements > language. > If folks agree that the descriptions are clear enough to proceed, we'll > adopt the RFC 2119 terms and move toward tighter specifications. >=20 > > - the draft does not differentiate between equal paths along different > > routers and equal paths > > between the same pair of routers (i.e. multiple parallel links). I > > think, the latter can't be detected. > > This should be clarified. > [ACM] > The concept of a *discoverable* host is at the root of your comment. > We haven't provided a formal definition for this term yet and it needs > some further discussion, but it will probably include the relevant > requirements for hosts and routers (RFC 1122), and some additional > requirements that apply for hybrid methods, at least. >=20 > Specific to your question: > If a pair of discovered hosts identify two different IP addresses, then > they will appear to be different hosts. >=20 > If a pair of discovered hosts identify two different IP addresses, and > the IP addresses resolve to the same host name (in the DNS), then they > will appear to be the same hosts. >=20 > If a discovered host always replies using the same IP address, > regardless of the interface a packet arrives on, then multiple parallel > links cannot be detected at the IP layer. >=20 > If parallel links between routers are aggregated below the IP layer, > IOW, all links share the same pair of IP addresses, then the existence > of these parallel links can't be detected at IP layer. >=20 >=20 > > - It is not clear how in-band-oam can be combined or used to complete > > the advanced route metrics. > > Especially the multi-domain and single-domain measurement should be > > decoupled more > > clearly. > [ACM] > Thanks, I think we all need to better understand what we'll be able to > do with the new hybrid methods (we are calling both the "new-ish" > active methods we describe, and new hybrid methods, "advanced" methods). > It seems likely that combinations of route information derived from > active and hybrid methods will provide additional information. > This is particularly true if hosts inside an in-situ domain are "not > discoverable" except when using Hybrid Type I methods. >=20 > > - If the authors think that the guidance "change several fields to > > keep the checksum of different > > packets identical" doesn't require any security discussion, the > > authors should say so in the > > security section. > [ACM] > Thanks for that. We only have the most basic security considerations > right now, which only address active and passive methods. > There will be *new* security considerations for Hybrid Type I methods, > and we certainly will reference them when available or add them in the > text. >=20 > We may also need to explain that the process you quoted above is only > part of the active methods, and it is executed at the Source host before > sending a packet. Perhaps that is sufficient explanation, unless I'm > overlooking something? >=20 > > > > Regards, > > > > Ruediger > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: ippm [mailto:ippm-bounces@ietf.org] Im Auftrag von MORTON, ALFRED > > C > > (AL) > > Gesendet: Donnerstag, 29. Juni 2017 03:10 > > An: ippm@ietf.org > > Cc: ippm-chairs@ietf.org > > Betreff: [ippm] New draft on Advanced Route Metrics and Measurements > > > > IPPM, > > > > Back at IETF-95 in Buenos Aires, the IPPM WG wanted to see some > > "traceroute" support in the Registry, but we didn't even have a metric > > to reference. > > Many methods were available, producing differing results. > > Now, with in-situ OAM, it's possible that there will be more advanced > > methods of measurement than ever before. > > There are also some interesting RTD analysis possibilities which we > > describe. We've been working on this draft in fits and starts since > > meeting in "BA". > > > > We invite IPPM'ers to read our draft and share your reactions and > > comments here. > > > > thanks and regards, > > Ignacio, Joachim, and Al > > > > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Advanced Unidirectional Route Assessment > > Authors : Jos=E9 Ignacio Alvarez-Hamelin > > Al Morton > > Joachim Fabini > > Filename : draft-amf-ippm-route-00.txt > > Pages : 17 > > Date : 2017-06-28 > > > > Abstract: > > This memo introduces an advanced unidirectional route assessment > > metric and associated measurement methodology, based on the IP > > Performance Metrics (IPPM) Framework RFC 2330. This memo updates > RFC > > 2330 in the areas of path-related terminology and path description, > > primarily to include the possibility of parallel subpaths. > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__tools.ietf.org_html_draft-2Damf-2Dippm-2Droute-2D00&d=3DDwIFAw&c=3D= LFY > > Z- > > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DV2yRRSNIWQVXxuQy- > > ZLI3oPhDjf_iSxw69Z_OiUManw&s=3DN99w_k6mo_iuyB- > > u3Jpp3jdMihOJNyOzJnfNzbhGQzQ&e=3D > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwIFAw&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DV2yRRSNIWQVXxuQy- > > ZLI3oPhDjf_iSxw69Z_OiUManw&s=3DLIgwFuKTWJdv9lbvno2SxHkMfMvFpFYRd5P9AQsX= Y > > Os > > &e=3D From nobody Fri Jun 30 08:30:04 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A7912F17A; Fri, 30 Jun 2017 08:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149883660241.4698.5852204302417708514@ietfa.amsl.com> Date: Fri, 30 Jun 2017 08:30:02 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-metric-registry-12.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 15:30:02 -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 of the IETF. Title : Registry for Performance Metrics Authors : Marcelo Bagnulo Benoit Claise Philip Eardley Al Morton Aamer Akhter Filename : draft-ietf-ippm-metric-registry-12.txt Pages : 33 Date : 2017-06-30 Abstract: This document defines the format for the Performance Metrics registry and defines the IANA Registry for Performance Metrics. 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-metric-registry-12 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-metric-registry-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-metric-registry-12 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 Jun 30 08:32:00 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5514C129AEB; Fri, 30 Jun 2017 08:31:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149883671931.4638.3148275958074948399@ietfa.amsl.com> Date: Fri, 30 Jun 2017 08:31:59 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-initial-registry-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 15:31: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 of the IETF. Title : Initial Performance Metric Registry Entries Authors : Al Morton Marcelo Bagnulo Philip Eardley Kevin D'Souza Filename : draft-ietf-ippm-initial-registry-04.txt Pages : 69 Date : 2017-06-30 Abstract: This memo defines the Initial Entries for the Performance Metrics Registry. This version includes: * Addition of Loss Ratio metric in various sections (multiple metrics per section). * All section 4, 5, 6, 7, and 8 parameters reference YANG types for alternate data formats. * implementation of standard naming format for parameters. * implementation of many IANA early-review comments. Still need: Add MBM metric entry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-initial-registry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-04 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-initial-registry-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-initial-registry-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 Fri Jun 30 10:19:03 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA94131442; Fri, 30 Jun 2017 10:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=ap0PJ/Of; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=I9wVuyWa 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 uw7HgPrrOrUW; Fri, 30 Jun 2017 10:18:53 -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 5CB82129AFE; Fri, 30 Jun 2017 10:18:53 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C2EE7207DA; Fri, 30 Jun 2017 13:18:52 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Fri, 30 Jun 2017 13:18:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=/vZrBg1POHSsbsT2v4fD0JgJ3yVVjwI68XZhHxOws O0=; b=ap0PJ/Of1MnrRa8IhT0Kz8rJGN6yAQfIRL4m7mQGApPQj0RZ82v2tE8h/ pzLjFolEs6jJw93hBsSYSW0UynlKnPnuZuk9jgj1APbrZPHGIbtiXkDw94xY8j5e Du+7VyQv6n5kQ44sgmwtw3pXhMij1KSUukwtSqSu+t8oLXXYlQrKR23+v8xFCMFp D1/zKcasgJvxqKzE7UtwYDVSdxGtcY0xCXAJGd89COKZMuxUAlA5sDrMN2JOH5Qk TxJoARYkXBSBqCjH5s050FdgNFwTD4d1qZHBRE4snJ+jQatPUKk+KjXUkAFOoPAt gioOe3ZL+Ezr+Zy2UNMLdxRV7ScYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=/vZrBg1POHSsbsT2v4 fD0JgJ3yVVjwI68XZhHxOwsO0=; b=I9wVuyWaVNef4xo+WpAJgk4kYDXFZHWqfh Z3eFr0T70VnnVeIEDOjGFNxw26kDweh+vYab1JuuaIPlpB1yyZJ32yxTrVwsfPY7 hXNBJTVAOiqyCgxBXCVYcqZZDjTkzr4kIV3g3zoFVSTCRjX9bQ0O42e7KepGAYbH PdqVWCQMSXIpYrgzwch1+MG30+9aFb6yLOXbwRTl3ppTXQSLDKuFhoU92ETlYWoj L0SGjrYWtP6LpRHzbSPDnIcSbvdm9cB+w80yA5Y0V8BplSSm84XBUdeIHxMrYrIG 7jEJzSSZ26bfXYi8R6CanHXOC9840uZxbHJXiNku9DJ29DwLAZ9Q== X-ME-Sender: X-Sasl-enc: vTGkJdvIXG8RMwndSc6BeFrgSdVnDqAta7jeMIHGZ3FR 1498843131 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.167]) by mail.messagingengine.com (Postfix) with ESMTPA id D4FAE7E4AA; Fri, 30 Jun 2017 13:18:50 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E3B207BE-001A-42C7-A170-9AEB27D4AE38" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <922169529.4233696.1495466806431@mail.yahoo.com> Date: Fri, 30 Jun 2017 13:18:49 -0400 Cc: IESG , "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , "acmorton@att.com" , "ippm@ietf.org" Message-Id: <4F5FBC6F-F92A-4A28-9A22-3EE9DD541CC4@cooperw.in> References: <149200885746.15718.798617550888585150.idtracker@ietfa.amsl.com> <922169529.4233696.1495466806431@mail.yahoo.com> To: Nalini J Elkins X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] Alissa Cooper's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 17:18:56 -0000 --Apple-Mail=_E3B207BE-001A-42C7-A170-9AEB27D4AE38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks, this seems better to me. Alissa > On May 22, 2017, at 11:26 AM, Nalini J Elkins = wrote: >=20 > Alissa, >=20 > Please let me know if you are OK with the proposed change. >=20 >=20 >=20 >=20 > >Alissa Cooper has entered the following ballot position for > >draft-ietf-ippm-6man-pdm-option-09: No Objection >=20 >=20 > >Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > >for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > >The document, along with other ballot positions, can be found here: > >https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ = >=20 >=20 >=20 > = >---------------------------------------------------------------------- > >COMMENT: > = >---------------------------------------------------------------------- >=20 > >The analysis in Sec 4.2 seems to be missing some considerations. In = cases > >where the packet payload is encrypted and the attacker does not have > >access to the keys, the attacker does not in fact have access to the > >entire packet, in which case PDM provides more information than a = packet > >without PDM. Also in those cases, it seems like including PDM = information > >would generally make a packet stream more susceptible to traffic = analysis > >insofar as the timing and sequence information may provide additional > >indicators about the type of application in use, not just the speed = of > >the end host. >=20 >=20 > Are you OK if I do the following: >=20 >=20 > OLD > ------ > Since PDM passes in the clear, a concern arises as to whether the > data can be used to fingerprint the system or somehow obtain > information about the contents of the payload. =20 >=20 > Let us discuss fingerprinting of the end host first. It is possible > that seeing the pattern of deltas or the absolute values could give > some information as to the speed of the end host - that is, if it is > a very fast system or an older, slow device. This may be useful to > the attacker. However, if the attacker has access to PDM, the > attacker also has access to the entire packet and could make such a > deduction based merely on the time frames elapsed between packets > WITHOUT PDM. =20 >=20 > As far as deducing the content of the payload, it appears to us that > PDM is quite unhelpful in this regard. >=20 >=20 >=20 > New > ------ >=20 > Since PDM passes in the clear, a concern arises as to whether the > data can be used to fingerprint the system or somehow obtain > information about the contents of the payload. =20 >=20 > Let us discuss fingerprinting of the end host first. It is possible > that seeing the pattern of deltas or the absolute values could give > some information as to the speed of the end host - that is, if it is > a very fast system or an older, slow device. This may be useful to > the attacker. However, if the attacker has access to PDM, the > attacker also has access to the entire packet and could make such a > deduction based merely on the time frames elapsed between packets > WITHOUT PDM. =20 >=20 > As far as deducing the content of the payload, it is conceivable > that an attacker could attempt to deduce the type of application in > use by noting the server time and payload length. Having said that, > some encryption algorithms attempt to obfuscate the packet length > to avoid just such vulnerabilities. In the future, encryption = algorithms > may wish to obfuscate the server time as well. =20 >=20 >=20 >=20 --Apple-Mail=_E3B207BE-001A-42C7-A170-9AEB27D4AE38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Thanks, this seems better to me.
Alissa

On May 22, 2017, at 11:26 AM, Nalini J Elkins = <nalini.elkins@insidethestack.com> wrote:

Alissa,

Please let me = know if you are OK with the proposed change.




>Alissa Cooper has entered the following ballot = position for
>draft-ietf-ippm-6man-pdm-option-09: No Objection


>for more information about IESG DISCUSS and COMMENT = positions.


>The document, along with other ballot positions, can be = found here:
>https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-optio= n/



>-----------------------------------------------------------= -----------
>COMMENT:
>-----------------------------------------------------------= -----------

>The analysis in Sec 4.2 seems to be missing some = considerations. In cases
>where the packet payload is encrypted and the attacker = does not have
>access to the keys, the attacker does not in fact have = access to the
>entire packet, in which case PDM provides more = information than a packet
>without PDM. Also in those cases, it seems like including = PDM information
>would generally make a packet stream more susceptible to = traffic analysis
>insofar as the timing and sequence information may = provide additional
>indicators about the type of application in use, not just = the speed of
>the end host.


Are you OK if I do the following:


OLD
------
 Since PDM passes in the clear, a concern arises as to = whether the
 data can be used to fingerprint the system or somehow = obtain
 information about the contents of the payload. =  

 Let us discuss fingerprinting of the end host first. It = is possible
 that seeing the pattern of deltas or the absolute = values could give
 some information as to the speed of the end host - that = is, if it is
 a= very fast system or an older, slow device.   This may be useful = to
 the attacker.  However, if the attacker has access = to PDM, the
 attacker also has access to the entire packet and could = make such a
 deduction based merely on the time frames elapsed = between packets
 WITHOUT PDM.  

 As far as deducing the content of the payload, it = appears to us that
 PDM is quite unhelpful in this regard.



New
------

Since = PDM passes in the clear, a concern arises as to whether the
data = can be used to fingerprint the system or somehow obtain
information about the contents of the payload. =  

Let = us discuss fingerprinting of the end host first. It is = possible
that = seeing the pattern of deltas or the absolute values could = give
some = information as to the speed of the end host - that is, if it = is
a = very fast system or an older, slow device.   This may be useful = to
the = attacker.  However, if the attacker has access to PDM, = the
attacker also has access to the entire packet and could make = such a
deduction based merely on the time frames elapsed between = packets
WITHOUT= PDM.  

As = far as deducing the content of the payload, it is = conceivable
that = an attacker could attempt to deduce the type of application = in
use = by noting the server time and payload length.   Having said = that,
some = encryption algorithms attempt to obfuscate the packet = length
to avoid just = such vulnerabilities.  In the future, encryption = algorithms
may = wish to obfuscate the server time as well.  



=

= --Apple-Mail=_E3B207BE-001A-42C7-A170-9AEB27D4AE38--