From nobody Wed Feb 1 18:20:18 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AA412948F for ; Wed, 1 Feb 2017 18:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 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=-3.199, SPF_PASS=-0.001] autolearn=unavailable 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 AIi-GRt6-j_y for ; Wed, 1 Feb 2017 18:20:15 -0800 (PST) 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 48D47129629 for ; Wed, 1 Feb 2017 18:14:21 -0800 (PST) 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 CZW29684; Thu, 02 Feb 2017 02:14:18 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 2 Feb 2017 02:13:34 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Wed, 1 Feb 2017 18:13:01 -0800 From: Haoyu song To: "ioam@ietf.org" Thread-Topic: [Ioam] suggestion to IOAM charter Thread-Index: AdJ8+Hj3gjasCRfGS5egJDBiiQePTA== Date: Thu, 2 Feb 2017 02:13:00 +0000 Message-ID: <78A2745BE9B57D4F9D27F86655EB87F9257E30C0@SJCEML703-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.217.92] Content-Type: multipart/alternative; boundary="_000_78A2745BE9B57D4F9D27F86655EB87F9257E30C0SJCEML703CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.589295FA.00DA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a2fa55b76cec664231b9a2ff04a720a6 Archived-At: Subject: [Ioam] suggestion to IOAM charter X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 02:20:17 -0000 --_000_78A2745BE9B57D4F9D27F86655EB87F9257E30C0SJCEML703CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like the idea of in-situ OAM and believe it has unique advantages to addr= ess many network OAM problems. We all agree today's hardware can do a lot more things than before and the = software-based network device is very flexible and becomes more popular. He= nce, I suggest to slightly extend the scope of in-situ OAM to take advantag= e of this and make the telemetry smarter by including a little bit in-netwo= rk programming and computing capability. I have talked about some related i= deas in dynamic network probe (https://datatracker.ietf.org/doc/slides-97-s= dnrg-33-dynamic-network-probes-on-programmable-data-plane/) and believe som= e of these ideas can be applied in in-situ OAM. For example, instead of asking each node to timestamp the packet, why don't= simply ask the data plane to directly report the path latency which is cal= culated by the timestamp at the path head and the packet arrival time at th= e path end. The packets only need to carry the timestamp of the first node = on the path. After all, the path latency is the actual information that the= network operator is interested in. Even better, we can tell the data plane= to report an event only when the path latency exceeds some predefined thre= shold, because in many case, the operator doesn't want to be flooded by nor= mal telemetry data and only care about anomalies. When the data plane is r= esponsible for doing such simple processing, it reduces the amount of raw d= ata and the network operator's work load, and allows faster reaction to net= work states. This would require the ability to dynamically install "programmable" probes= in to data plane and require the packet format to be flexible enough to ca= rry custom data. While not all data plane devices can support this immediat= ely, this can significantly expand the flexibility and applicability of the= in-situ OAM, so these use cases are better to be considered and covered no= w rather than later. Any comments and suggestions? Thanks! -Haoyu --_000_78A2745BE9B57D4F9D27F86655EB87F9257E30C0SJCEML703CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like the idea of in-situ OAM and believe it has un= ique advantages to address many network OAM problems.

We all agree today’s hardware can do a lot mor= e things than before and the software-based network device is very flexible= and becomes more popular. Hence, I suggest to slightly extend the scope of= in-situ OAM to take advantage of this and make the telemetry smarter by including a little bit in-network programmin= g and computing capability. I have talked about some related ideas in dynam= ic network probe (https://datatrack= er.ietf.org/doc/slides-97-sdnrg-33-dynamic-network-probes-on-programmable-d= ata-plane/) and believe some of these ideas can be applied in in-situ OAM.<= /p>

For example, instead of asking each node to timestam= p the packet, why don’t simply ask the data plane to directly report = the path latency which is calculated by the timestamp at the path head and = the packet arrival time at the path end. The packets only need to carry the timestamp of the first node on the path= . After all, the path latency is the actual information that the network op= erator is interested in. Even better, we can tell the data plane to report = an event only when the path latency exceeds some predefined threshold, because in many case, the operator does= n’t want to be flooded by normal telemetry data and only care about a= nomalies.  When the data plane is responsible for doing such simple pr= ocessing, it reduces the amount of raw data and the network operator’s work load, and allows faster reaction to = network states.

This would require the ability to dynamically instal= l “programmable” probes in to data plane and require the packet= format to be flexible enough to carry custom data. While not all data plan= e devices can support this immediately, this can significantly expand the flexibility and applicability of the in-situ OAM,= so these use cases are better to be considered and covered now rather than= later. 

Any comments and suggestions?

Thanks!

-Haoyu

--_000_78A2745BE9B57D4F9D27F86655EB87F9257E30C0SJCEML703CHMchi_-- From nobody Tue Feb 7 02:10:24 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA54129506 for ; Tue, 7 Feb 2017 02:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 5efkx5_5mkHh for ; Tue, 7 Feb 2017 02:10:21 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8428012949F for ; Tue, 7 Feb 2017 02:10:20 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v17AAHPh004775 for ; Tue, 7 Feb 2017 10:10:17 GMT Received: from 950129200 ([176.241.251.3]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v17AABOq004668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Feb 2017 10:10:14 GMT From: "Adrian Farrel" To: Date: Tue, 7 Feb 2017 10:10:11 -0000 Message-ID: <02fb01d2812a$616675c0$24336140$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKBKdv29U4eOQyIRNK5qzVMRLEMgQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22870.006 X-TM-AS-Result: No--1.464-10.0-31-10 X-imss-scan-details: No--1.464-10.0-31-10 X-TMASE-MatchedRID: C87LQYwZgTnLmPsfsKViB7xygpRxo469cHdSqDyzIhRGr8G3v23M35mX ZhN9+ICRIo6UU+t8zgSVqvCa99mSszwLWgs3zoywngIgpj8eDcC063Wh9WVqgnXA+T8YcZkD1Ao zErC5dcfkwjHXXC/4I8ZW5ai5WKlylBUGfUVCZUBf4Bl//TnW74yArTlr1lkbJjqXc5phvhkkOf 5lvt2aKSYzqaMJ+iqe50rp9kMD/aCU8ItxIXtesmo983r4EiwcNhaOBHxzal2OTCSnRTeg+iPVI UGLlI4nRt01ZrBZr35mO3qi78sNJA== Archived-At: Subject: [Ioam] Room size and meeting conflicts if BoF is granted X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 10:10:23 -0000 I see the BoF wiki suggests that you don't expect more than 50 people at your BoF. It seems to me that quite a lot of INT and RTG people will want to attend. Please make sure that the room is large enough - BoFs where (for example) late-arriving WG chairs and ADs can't physically get into the room are rarely successful BoFs. You should probably try to avoid conflicts with all of the technologies that might be consumers, and all of those WGs that you have already identified on this list as having potential overlap or usage. Adrian From nobody Tue Feb 7 06:02:59 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7D7129C35 for ; Tue, 7 Feb 2017 06:02:58 -0800 (PST) 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 tZlzFUj17ms9 for ; Tue, 7 Feb 2017 06:02:57 -0800 (PST) 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 02D21129C34 for ; Tue, 7 Feb 2017 06:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1065; q=dns/txt; s=iport; t=1486476177; x=1487685777; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=baa34Pn1T3O+EY9L6IT3r0DxaRzKcI6wvEyMbuYdVVU=; b=VPXKWX+gu7ao+Ed+UZUE1h7QRCzdnV3Zm1+smFxR0Mi1t1KrqL8Qe94S 0bvV8XzraMWiGkaIprPLslTvbCcvHhVrxdihmnVgUaDtHiylsJ4g4+i6I /QpJunn7cMIjpGGcBPsVUFw+mA7xqpFHvwjgW7kLIlsNR+xpqifh9CYs3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQD40plY/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVmSD5U2ggwfC4V4AoJOPxgBAgEBAQEBAQFiKIRpAQE?= =?us-ascii?q?BBAEBODQXBAIBCBEEAQEfCQcnCxQJCAEBBAESCIlrDrIHi1UBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYZMhG+KOQWbawGGaYsbggSFF4lxkw4BHzh+TxU8hkJ1AYg?= =?us-ascii?q?RgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="203892651" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Feb 2017 14:02:56 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v17E2u7L024499 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Feb 2017 14:02:56 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Feb 2017 08:02:55 -0600 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, 7 Feb 2017 08:02:55 -0600 From: "Frank Brockners (fbrockne)" To: "adrian@olddog.co.uk" , "ioam@ietf.org" Thread-Topic: [Ioam] Room size and meeting conflicts if BoF is granted Thread-Index: AdKBKdv29U4eOQyIRNK5qzVMRLEMgQAIM76w Date: Tue, 7 Feb 2017 14:02:55 +0000 Message-ID: References: <02fb01d2812a$616675c0$24336140$@olddog.co.uk> In-Reply-To: <02fb01d2812a$616675c0$24336140$@olddog.co.uk> 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.190.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ioam] Room size and meeting conflicts if BoF is granted X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 14:02:58 -0000 Adrian, thanks - good point. I've updated the wiki (https://trac.tools.ietf.org/bof= /trac/) to now ask for a room that fits 100. Frank -----Original Message----- From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Dienstag, 7. Februar 2017 11:10 To: ioam@ietf.org Subject: [Ioam] Room size and meeting conflicts if BoF is granted I see the BoF wiki suggests that you don't expect more than 50 people at yo= ur BoF.=20 It seems to me that quite a lot of INT and RTG people will want to attend. Please make sure that the room is large enough - BoFs where (for example) l= ate-arriving WG chairs and ADs can't physically get into the room are rarel= y successful BoFs. You should probably try to avoid conflicts with all of the technologies tha= t might be consumers, and all of those WGs that you have already identified= on this list as having potential overlap or usage. Adrian _______________________________________________ Ioam mailing list Ioam@ietf.org https://www.ietf.org/mailman/listinfo/ioam From nobody Tue Feb 7 08:36:46 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE14129D0C for ; Tue, 7 Feb 2017 08:36:44 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 v29q5DQfadx1 for ; Tue, 7 Feb 2017 08:36:43 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 D4349129412 for ; Tue, 7 Feb 2017 08:36:42 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v17GFADd031145 for ; Tue, 7 Feb 2017 08:17:19 -0800 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 28fhk2g0f2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 07 Feb 2017 08:17:19 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Feb 2017 18:17:15 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1210.000; Tue, 7 Feb 2017 18:17:15 +0200 From: Tal Mizrahi To: "ioam@ietf.org" Thread-Topic: Updated Draft Charter Thread-Index: AdKBXSf8IEPKgEUSQXuQu+bACqJyPw== Date: Tue, 7 Feb 2017 16:17:15 +0000 Message-ID: <973f34567c5645c3a5ad3f6e0b052d50@IL-EXCH01.marvell.com> 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: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_973f34567c5645c3a5ad3f6e0b052d50ILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-07_08:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound 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-1612050000 definitions=main-1702070155 Archived-At: Subject: [Ioam] Updated Draft Charter X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:36:44 -0000 --_000_973f34567c5645c3a5ad3f6e0b052d50ILEXCH01marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, An updated draft charter can be found below. The draft has been updated bas= ed on the comments received on the mailing list in the last few days. Many thanks to Shwetha and Frank for ironing out the text. Comments will be welcome. Cheers, Tal. IOAM working group charter In-situ OAM provides real-time telemetry of individual data packets and flo= ws. It is based on telemetry information which is embedded within live data= packets. The IOAM WG intends to define data formats and associated procedu= res for in-situ OAM, including mechanisms for capturing path and path-trave= rsal related information as well as procedures to employ, configure, trigge= r, and export the embedded telemetry information. The IOAM WG will define the following in-situ OAM components: * Data-records for in-situ OAM to cover path-tracing and path verification = information (node-ids, ingress/egress interfaces), timestamps, transit-dela= y, transit jitter, sequence numbers, application-defined metadata. In-situ = OAM data-records are defined using an in-situ OAM namespace. It should be p= ossible to control the information that gets recorded in data-records. * Procedures to add, update, remove, retrieve and export data-records for i= n-situ OAM to live traffic and active probing. In case of live traffic a c= lassifier to select subset of live traffic for addition, update, removal an= d retrieval of in-situ OAM data-records. In case of active probing procedur= e to return the in-situ OAM data records to the source of the probe. * Scope of in-situ OAM operation. In-Situ OAM operations are defined for a= specific operational domain. In-situ OAM data-records are added and remove= d at domain boundaries and updated by nodes within the in-situ OAM domain. = Procedure to deal with various challenges in packet forwarding and error ha= ndling such as ECMP processing, path MTU and ICMP message handling when in-= situ OAM is enabled in an in-situ OAM domain. * Data-records for in-situ OAM are to be defined in a way that makes them = independent from the transport protocol used. Data-records for in-situ OAM = will need to be embedded into transport protocols such as IPv4, IPv6, VXLAN= -GPE, LISP, NSH, SRv6, Geneve. * Procedures and data-records optimized for software dataplane and hardware= dataplane implementations of in-situ OAM. * In-situ OAM to support layering. If several transport protocols (e.g. in = case of tunneling) are stacked on top of each other, in-situ OAM data-recor= ds could be present in every transport protocol layer. * Management and control of role of nodes for in-situ OAM operation, dynami= c control of in-situ OAM data collected in the data records, data export op= timization. The IOAM working group intends to work on and publish: * Definition of the data-type formats used in in-situ OAM and namespaces fo= r in-situ OAM. * Definition of procedures that in-situ OAM enabled nodes will perform on d= ata traffic that carries in-situ OAM information (e.g., introducing, removi= ng, processing, modifying, and exporting the telemetry information from the= associated data packets). * Configuration and operational data models for controlling in-situ OAM dat= a and operations. In-situ OAM data records could be embedded into a variety of transports. Th= e transports are expected to be defined in the respective working group(s) = like NVO3, SFC, 6man, MPLS etc in consultation with the IOAM working group = documents. IOAM WG exclusively focuses on mechanisms which piggyback OAM-re= lated metadata onto en-route traffic for OAM purposes. Other ongoing OAM-re= lated efforts in working groups(s) such as MPLS and IPPM that do not piggyb= ack information onto the live user data traffic are out of scope of the IOA= M WG. Milestones April 2018 - submit data format and associated procedures document to IESG. March 2018 - WGLC for data format and associated procedures document. April 2017 - working group adoption of data format and associated procedure= s document --_000_973f34567c5645c3a5ad3f6e0b052d50ILEXCH01marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

An updated draft charter can be found below. The dra= ft has been updated based on the comments received on the mailing list in t= he last few days.

Many thanks to Shwetha and Frank for ironing out the= text.

 

Comments will be welcome.

 

Cheers,

Tal.

 

 

IOAM working group charter

 

In-situ OAM provides real-time telemetry of individu= al data packets and flows. It is based on telemetry information which is em= bedded within live data packets. The IOAM WG intends to define data formats= and associated procedures for in-situ OAM, including mechanisms for capturing path and path-traversal related in= formation as well as procedures to employ, configure, trigger, and export t= he embedded telemetry information. 

 

The IOAM WG will define the following in-situ OAM co= mponents:

 

* Data-records for in-situ OAM to cover path-tracing= and path verification information (node-ids, ingress/egress interfaces), t= imestamps, transit-delay, transit jitter, sequence numbers, application-def= ined metadata. In-situ OAM data-records are defined using an in-situ OAM namespace. It should be possible to contr= ol the information that gets recorded in data-records.

* Procedures to add, update, remove, retrieve and ex= port data-records for in-situ OAM to live traffic and active probing. = In case of live traffic a classifier to select subset of live traffic for = addition, update, removal and retrieval of in-situ OAM data-records. In case of active probing procedure to return= the in-situ OAM data records to the source of the probe.

*  Scope of in-situ OAM operation. In-Situ OAM = operations are defined for a specific operational domain. In-situ OAM data-= records are added and removed at domain boundaries and updated by nodes wit= hin the in-situ OAM domain. Procedure to deal with various challenges in packet forwarding and error handling such = as ECMP processing, path MTU and ICMP message handling when in-situ OAM is = enabled in an in-situ OAM domain.

*  Data-records for in-situ OAM are to be defin= ed in a way that makes them independent from the transport protocol used. D= ata-records for in-situ OAM will need to be embedded into transport protoco= ls such as IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, Geneve.

* Procedures and data-records optimized for software= dataplane and hardware dataplane implementations of in-situ OAM.

* In-situ OAM to support layering. If several transp= ort protocols (e.g. in case of tunneling) are stacked on top of each other,= in-situ OAM data-records could be present in every transport protocol laye= r.

* Management and control of role of nodes for in-sit= u OAM operation, dynamic control of in-situ OAM data collected in the data = records, data export optimization.

 

The IOAM working group intends to work on and publis= h:

* Definition of the data-type formats used in in-sit= u OAM and namespaces for in-situ OAM.

* Definition of procedures that in-situ OAM enabled = nodes will perform on data traffic that carries in-situ OAM information (e.= g., introducing, removing, processing, modifying, and exporting the telemet= ry information from the associated data packets).

* Configuration and operational data models for cont= rolling in-situ OAM data and operations.

In-situ OAM data records could be embedded into a va= riety of transports. The transports are expected to be defined in the respe= ctive working group(s) like NVO3, SFC, 6man, MPLS etc in consultation with = the IOAM working group documents. IOAM WG exclusively focuses on mechanisms which piggyback OAM-related meta= data onto en-route traffic for OAM purposes. Other ongoing OAM-related effo= rts in working groups(s) such as MPLS and IPPM that do not piggyback inform= ation onto the live user data traffic are out of scope of the IOAM WG.

 

Milestones

 

April 2018 - submit data format and associated proce= dures document to IESG.

March 2018 - WGLC for data format and associated pro= cedures document.

April 2017 - working group adoption of data format a= nd associated procedures document

--_000_973f34567c5645c3a5ad3f6e0b052d50ILEXCH01marvellcom_-- From nobody Wed Feb 8 07:14:44 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED578120724 for ; Wed, 8 Feb 2017 07:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 aeF3WvgRW6iP for ; Wed, 8 Feb 2017 07:14:41 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 0B83F129BBA for ; Wed, 8 Feb 2017 07:07:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id E9560A401CD for ; Wed, 8 Feb 2017 07:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486566424; bh=QtgCtvfXXk2dFf+2bqDu9/Gj8lz2n/LQV+RKtXDydPk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=FbFE7Kz1WyocwXFBAxkE5BPcV66S/x7fduKcaPvA8B3CYiVF/f7nrqHRQpbnXg2g3 DbzUrq063kWwyYINzwk1aRL0j6/qIHrLXHSeTN9SKUup3zEzxLZugfD5GoQWZqI+nI CZyXoRbMjwyCGDtvNeHwr2cmAQyrB+rJCOHgv3U0= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MBP.home (pool-98-114-54-105.phlapa.fios.verizon.net [98.114.54.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 7B0A824ECF8 for ; Wed, 8 Feb 2017 07:07:04 -0800 (PST) To: "ioam@ietf.org" References: <973f34567c5645c3a5ad3f6e0b052d50@IL-EXCH01.marvell.com> From: "Joel M. Halpern" Message-ID: <7eb6471e-9830-e369-ce18-9b08a764e3cb@joelhalpern.com> Date: Wed, 8 Feb 2017 10:07:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <973f34567c5645c3a5ad3f6e0b052d50@IL-EXCH01.marvell.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ioam] Updated Draft Charter X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:14:43 -0000 Doesn't there need to be some discussion in the charter of the constraints within which this work is to be done? As written, this would sem to allow any and all mechanisms, withour\t regard to issues such as MTU, complexity of expanding or contracting packets, exposure of information across administrative boundaries, or any of the other real world constraints which will affect the utility and deployability of this work. Yours, Joel On 2/7/17 11:17 AM, Tal Mizrahi wrote: > Hi, > > > > An updated draft charter can be found below. The draft has been updated > based on the comments received on the mailing list in the last few days. > > Many thanks to Shwetha and Frank for ironing out the text. > > > > Comments will be welcome. > > > > Cheers, > > Tal. > > > > > > IOAM working group charter > > > > In-situ OAM provides real-time telemetry of individual data packets and > flows. It is based on telemetry information which is embedded within > live data packets. The IOAM WG intends to define data formats and > associated procedures for in-situ OAM, including mechanisms for > capturing path and path-traversal related information as well as > procedures to employ, configure, trigger, and export the embedded > telemetry information. > > > > The IOAM WG will define the following in-situ OAM components: > > > > * Data-records for in-situ OAM to cover path-tracing and path > verification information (node-ids, ingress/egress interfaces), > timestamps, transit-delay, transit jitter, sequence numbers, > application-defined metadata. In-situ OAM data-records are defined using > an in-situ OAM namespace. It should be possible to control the > information that gets recorded in data-records. > > * Procedures to add, update, remove, retrieve and export data-records > for in-situ OAM to live traffic and active probing. In case of live > traffic a classifier to select subset of live traffic for addition, > update, removal and retrieval of in-situ OAM data-records. In case of > active probing procedure to return the in-situ OAM data records to the > source of the probe. > > * Scope of in-situ OAM operation. In-Situ OAM operations are defined > for a specific operational domain. In-situ OAM data-records are added > and removed at domain boundaries and updated by nodes within the in-situ > OAM domain. Procedure to deal with various challenges in packet > forwarding and error handling such as ECMP processing, path MTU and ICMP > message handling when in-situ OAM is enabled in an in-situ OAM domain. > > * Data-records for in-situ OAM are to be defined in a way that makes > them independent from the transport protocol used. Data-records for > in-situ OAM will need to be embedded into transport protocols such as > IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, Geneve. > > * Procedures and data-records optimized for software dataplane and > hardware dataplane implementations of in-situ OAM. > > * In-situ OAM to support layering. If several transport protocols (e.g. > in case of tunneling) are stacked on top of each other, in-situ OAM > data-records could be present in every transport protocol layer. > > * Management and control of role of nodes for in-situ OAM operation, > dynamic control of in-situ OAM data collected in the data records, data > export optimization. > > > > The IOAM working group intends to work on and publish: > > * Definition of the data-type formats used in in-situ OAM and namespaces > for in-situ OAM. > > * Definition of procedures that in-situ OAM enabled nodes will perform > on data traffic that carries in-situ OAM information (e.g., introducing, > removing, processing, modifying, and exporting the telemetry information > from the associated data packets). > > * Configuration and operational data models for controlling in-situ OAM > data and operations. > > In-situ OAM data records could be embedded into a variety of transports. > The transports are expected to be defined in the respective working > group(s) like NVO3, SFC, 6man, MPLS etc in consultation with the IOAM > working group documents. IOAM WG exclusively focuses on mechanisms which > piggyback OAM-related metadata onto en-route traffic for OAM purposes. > Other ongoing OAM-related efforts in working groups(s) such as MPLS and > IPPM that do not piggyback information onto the live user data traffic > are out of scope of the IOAM WG. > > > > Milestones > > > > April 2018 - submit data format and associated procedures document to IESG. > > March 2018 - WGLC for data format and associated procedures document. > > April 2017 - working group adoption of data format and associated > procedures document > > > > _______________________________________________ > Ioam mailing list > Ioam@ietf.org > https://www.ietf.org/mailman/listinfo/ioam > From nobody Wed Feb 8 07:32:09 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C158129BBD for ; Wed, 8 Feb 2017 07:32:07 -0800 (PST) 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 v9Mahf5JrOJc for ; Wed, 8 Feb 2017 07:32:05 -0800 (PST) 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 E33E1129BC8 for ; Wed, 8 Feb 2017 07:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8306; q=dns/txt; s=iport; t=1486567924; x=1487777524; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FEr5yKdTihrRfV7ImiBq0TBczPisOHVgIV+K8Gatq+k=; b=YbvmVhspiCNCPe/N/YvYJbCI4cH0b38aBpMNrrT5CitCO+Y+PW2hGUZl zzBzru/qe5p3AOSYYUNWaddHG+bs3mQeH7fLGi9O7+I5q8qAvR2cR0RkZ X6O6vZZ6SPHkNRiP8ryQhJg30HteEImU0fyvJfh1qZmJ67zz7wWkJYojI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BpAQDaOJtY/4MNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHg1KKCJIJlTaCDB8LgkKDNgIagk8/GAECAQEBAQEBAWI?= =?us-ascii?q?ohGkBAQEDAQEBIREzBwsFCwIBCBgCAiYCAgIlCxUQAQEEDgWJbAgOsAqCJYtIA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VBggWCaoRUgwYugjEFlVSGHAGSEYF?= =?us-ascii?q?7jwqILIpmAR84fk8VPBEBhjB1h3KBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,348,1477958400"; d="scan'208";a="382987093" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2017 15:32:01 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v18FW1nH029332 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Feb 2017 15:32:01 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Feb 2017 10:32:00 -0500 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, 8 Feb 2017 10:31:59 -0500 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" Thread-Topic: [Ioam] Updated Draft Charter Thread-Index: AdKBXSf8IEPKgEUSQXuQu+bACqJyPwA6cHiAAADe64A= Date: Wed, 8 Feb 2017 15:31:59 +0000 Message-ID: <347D9679-97E1-49D5-B9BB-8FA5C287DC80@cisco.com> References: <973f34567c5645c3a5ad3f6e0b052d50@IL-EXCH01.marvell.com> <7eb6471e-9830-e369-ce18-9b08a764e3cb@joelhalpern.com> In-Reply-To: <7eb6471e-9830-e369-ce18-9b08a764e3cb@joelhalpern.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.150.49.171] Content-Type: text/plain; charset="utf-8" Content-ID: <82DC2E6D64092C4D90B75C42372D6395@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ioam@ietf.org" Subject: Re: [Ioam] Updated Draft Charter X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:32:07 -0000 SGksIEpvZWwsDQoNClRoaXMgaXMgYSBnb29kIHBvaW50LiBNb3N0IG9mIHRob3NlIGNvbnNpZGVy YXRpb25zIGFyZSB1bmRlciB0aGUgJ1Njb3BlIG9mIGluLXNpdHUgT0FNIG9wZXJhdGlvbuKAmSBo ZWFkaW5nIGFscmVhZHksIGFzIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zLg0KDQpJIHdvdWxk IG5vdCBtaW5kIGJlaW5nIGEgdGFkIG1vcmUgcHJlc2NyaXB0aXZlOyBwZXJoYXBzIHdlIGNhbiBh ZGQgdGhhdCDigJxTcGVjaWZpY2FsbHksIHRoZSBwcm9jZWR1cmVzIGxpc3QgYW5kIGV2YWx1YXRl IGNvbnNpZGVyYXRpb25zIGFuZCBjb25zdHJhaW5zIGltcG9zZWQgZHVlIHRvIE1UVSBhbmQgcGFj a2V0IHNpemVzLCBhcyB3ZWxsIGFzIGRvbWFpbiBib3VuZGFyeSBpbXBsaWNhdGlvbnMu4oCdDQoN Ck9yIGFyZSB5b3UgdGhpbmtpbmcgYWJvdXQgY29kaWZ5aW5nIG1vcmUgc3BlY2lmaWNzIGluIHRo ZSBjaGFydGVyIGl0c2VsZj8gSSB0aGluayBhZGRpbmcgc3VjaCBhIHNlbnRlbmNlIHdvdWxkIGNs b3NlIGFueSBwb3RlbnRpYWwgd2VkZ2UgaW4gdGhlIGNoYXJ0ZXIsIGJ1dCBvdGhlcndpc2UgY2Fu IHlvdSBzaGFyZSBtb3JlIHNwZWNpZmljcz8NCg0KVGhhbmtzIQ0KDQrigJQNCkNhcmxvcyBQaWdu YXRhcm8sIGNhcmxvc0BjaXNjby5jb20NCg0K4oCcU29tZXRpbWVzIEkgdXNlIGJpZyB3b3JkcyB0 aGF0IEkgZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1ha2UgbXlzZWxmIHNvdW5kIG1vcmUg cGhvdG9zeW50aGVzaXMuIg0KDQo+IE9uIEZlYiA4LCAyMDE3LCBhdCAxMDowNyBBTSwgSm9lbCBN LiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4gDQo+IERvZXNuJ3QgdGhl cmUgbmVlZCB0byBiZSBzb21lIGRpc2N1c3Npb24gaW4gdGhlIGNoYXJ0ZXIgb2YgdGhlIGNvbnN0 cmFpbnRzIHdpdGhpbiB3aGljaCB0aGlzIHdvcmsgaXMgdG8gYmUgZG9uZT8gIEFzIHdyaXR0ZW4s IHRoaXMgd291bGQgc2VtIHRvIGFsbG93IGFueSBhbmQgYWxsIG1lY2hhbmlzbXMsIHdpdGhvdXJc dCByZWdhcmQgdG8gaXNzdWVzIHN1Y2ggYXMgTVRVLCBjb21wbGV4aXR5IG9mIGV4cGFuZGluZyBv ciBjb250cmFjdGluZyBwYWNrZXRzLCBleHBvc3VyZSBvZiBpbmZvcm1hdGlvbiBhY3Jvc3MgYWRt aW5pc3RyYXRpdmUgYm91bmRhcmllcywgb3IgYW55IG9mIHRoZSBvdGhlciByZWFsIHdvcmxkIGNv bnN0cmFpbnRzIHdoaWNoIHdpbGwgYWZmZWN0IHRoZSB1dGlsaXR5IGFuZCBkZXBsb3lhYmlsaXR5 IG9mIHRoaXMgd29yay4NCj4gDQo+IFlvdXJzLA0KPiBKb2VsDQo+IA0KPiBPbiAyLzcvMTcgMTE6 MTcgQU0sIFRhbCBNaXpyYWhpIHdyb3RlOg0KPj4gSGksDQo+PiANCj4+IA0KPj4gDQo+PiBBbiB1 cGRhdGVkIGRyYWZ0IGNoYXJ0ZXIgY2FuIGJlIGZvdW5kIGJlbG93LiBUaGUgZHJhZnQgaGFzIGJl ZW4gdXBkYXRlZA0KPj4gYmFzZWQgb24gdGhlIGNvbW1lbnRzIHJlY2VpdmVkIG9uIHRoZSBtYWls aW5nIGxpc3QgaW4gdGhlIGxhc3QgZmV3IGRheXMuDQo+PiANCj4+IE1hbnkgdGhhbmtzIHRvIFNo d2V0aGEgYW5kIEZyYW5rIGZvciBpcm9uaW5nIG91dCB0aGUgdGV4dC4NCj4+IA0KPj4gDQo+PiAN Cj4+IENvbW1lbnRzIHdpbGwgYmUgd2VsY29tZS4NCj4+IA0KPj4gDQo+PiANCj4+IENoZWVycywN Cj4+IA0KPj4gVGFsLg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IElPQU0gd29ya2luZyBn cm91cCBjaGFydGVyDQo+PiANCj4+IA0KPj4gDQo+PiBJbi1zaXR1IE9BTSBwcm92aWRlcyByZWFs LXRpbWUgdGVsZW1ldHJ5IG9mIGluZGl2aWR1YWwgZGF0YSBwYWNrZXRzIGFuZA0KPj4gZmxvd3Mu IEl0IGlzIGJhc2VkIG9uIHRlbGVtZXRyeSBpbmZvcm1hdGlvbiB3aGljaCBpcyBlbWJlZGRlZCB3 aXRoaW4NCj4+IGxpdmUgZGF0YSBwYWNrZXRzLiBUaGUgSU9BTSBXRyBpbnRlbmRzIHRvIGRlZmlu ZSBkYXRhIGZvcm1hdHMgYW5kDQo+PiBhc3NvY2lhdGVkIHByb2NlZHVyZXMgZm9yIGluLXNpdHUg T0FNLCBpbmNsdWRpbmcgbWVjaGFuaXNtcyBmb3INCj4+IGNhcHR1cmluZyBwYXRoIGFuZCBwYXRo LXRyYXZlcnNhbCByZWxhdGVkIGluZm9ybWF0aW9uIGFzIHdlbGwgYXMNCj4+IHByb2NlZHVyZXMg dG8gZW1wbG95LCBjb25maWd1cmUsIHRyaWdnZXIsIGFuZCBleHBvcnQgdGhlIGVtYmVkZGVkDQo+ PiB0ZWxlbWV0cnkgaW5mb3JtYXRpb24uDQo+PiANCj4+IA0KPj4gDQo+PiBUaGUgSU9BTSBXRyB3 aWxsIGRlZmluZSB0aGUgZm9sbG93aW5nIGluLXNpdHUgT0FNIGNvbXBvbmVudHM6DQo+PiANCj4+ IA0KPj4gDQo+PiAqIERhdGEtcmVjb3JkcyBmb3IgaW4tc2l0dSBPQU0gdG8gY292ZXIgcGF0aC10 cmFjaW5nIGFuZCBwYXRoDQo+PiB2ZXJpZmljYXRpb24gaW5mb3JtYXRpb24gKG5vZGUtaWRzLCBp bmdyZXNzL2VncmVzcyBpbnRlcmZhY2VzKSwNCj4+IHRpbWVzdGFtcHMsIHRyYW5zaXQtZGVsYXks IHRyYW5zaXQgaml0dGVyLCBzZXF1ZW5jZSBudW1iZXJzLA0KPj4gYXBwbGljYXRpb24tZGVmaW5l ZCBtZXRhZGF0YS4gSW4tc2l0dSBPQU0gZGF0YS1yZWNvcmRzIGFyZSBkZWZpbmVkIHVzaW5nDQo+ PiBhbiBpbi1zaXR1IE9BTSBuYW1lc3BhY2UuIEl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBjb250 cm9sIHRoZQ0KPj4gaW5mb3JtYXRpb24gdGhhdCBnZXRzIHJlY29yZGVkIGluIGRhdGEtcmVjb3Jk cy4NCj4+IA0KPj4gKiBQcm9jZWR1cmVzIHRvIGFkZCwgdXBkYXRlLCByZW1vdmUsIHJldHJpZXZl IGFuZCBleHBvcnQgZGF0YS1yZWNvcmRzDQo+PiBmb3IgaW4tc2l0dSBPQU0gdG8gbGl2ZSB0cmFm ZmljIGFuZCBhY3RpdmUgcHJvYmluZy4gIEluIGNhc2Ugb2YgbGl2ZQ0KPj4gdHJhZmZpYyBhIGNs YXNzaWZpZXIgdG8gc2VsZWN0IHN1YnNldCBvZiBsaXZlIHRyYWZmaWMgZm9yIGFkZGl0aW9uLA0K Pj4gdXBkYXRlLCByZW1vdmFsIGFuZCByZXRyaWV2YWwgb2YgaW4tc2l0dSBPQU0gZGF0YS1yZWNv cmRzLiBJbiBjYXNlIG9mDQo+PiBhY3RpdmUgcHJvYmluZyBwcm9jZWR1cmUgdG8gcmV0dXJuIHRo ZSBpbi1zaXR1IE9BTSBkYXRhIHJlY29yZHMgdG8gdGhlDQo+PiBzb3VyY2Ugb2YgdGhlIHByb2Jl Lg0KPj4gDQo+PiAqICBTY29wZSBvZiBpbi1zaXR1IE9BTSBvcGVyYXRpb24uIEluLVNpdHUgT0FN IG9wZXJhdGlvbnMgYXJlIGRlZmluZWQNCj4+IGZvciBhIHNwZWNpZmljIG9wZXJhdGlvbmFsIGRv bWFpbi4gSW4tc2l0dSBPQU0gZGF0YS1yZWNvcmRzIGFyZSBhZGRlZA0KPj4gYW5kIHJlbW92ZWQg YXQgZG9tYWluIGJvdW5kYXJpZXMgYW5kIHVwZGF0ZWQgYnkgbm9kZXMgd2l0aGluIHRoZSBpbi1z aXR1DQo+PiBPQU0gZG9tYWluLiBQcm9jZWR1cmUgdG8gZGVhbCB3aXRoIHZhcmlvdXMgY2hhbGxl bmdlcyBpbiBwYWNrZXQNCj4+IGZvcndhcmRpbmcgYW5kIGVycm9yIGhhbmRsaW5nIHN1Y2ggYXMg RUNNUCBwcm9jZXNzaW5nLCBwYXRoIE1UVSBhbmQgSUNNUA0KPj4gbWVzc2FnZSBoYW5kbGluZyB3 aGVuIGluLXNpdHUgT0FNIGlzIGVuYWJsZWQgaW4gYW4gaW4tc2l0dSBPQU0gZG9tYWluLg0KPj4g DQo+PiAqICBEYXRhLXJlY29yZHMgZm9yIGluLXNpdHUgT0FNIGFyZSB0byBiZSBkZWZpbmVkIGlu IGEgd2F5IHRoYXQgbWFrZXMNCj4+IHRoZW0gaW5kZXBlbmRlbnQgZnJvbSB0aGUgdHJhbnNwb3J0 IHByb3RvY29sIHVzZWQuIERhdGEtcmVjb3JkcyBmb3INCj4+IGluLXNpdHUgT0FNIHdpbGwgbmVl ZCB0byBiZSBlbWJlZGRlZCBpbnRvIHRyYW5zcG9ydCBwcm90b2NvbHMgc3VjaCBhcw0KPj4gSVB2 NCwgSVB2NiwgVlhMQU4tR1BFLCBMSVNQLCBOU0gsIFNSdjYsIEdlbmV2ZS4NCj4+IA0KPj4gKiBQ cm9jZWR1cmVzIGFuZCBkYXRhLXJlY29yZHMgb3B0aW1pemVkIGZvciBzb2Z0d2FyZSBkYXRhcGxh bmUgYW5kDQo+PiBoYXJkd2FyZSBkYXRhcGxhbmUgaW1wbGVtZW50YXRpb25zIG9mIGluLXNpdHUg T0FNLg0KPj4gDQo+PiAqIEluLXNpdHUgT0FNIHRvIHN1cHBvcnQgbGF5ZXJpbmcuIElmIHNldmVy YWwgdHJhbnNwb3J0IHByb3RvY29scyAoZS5nLg0KPj4gaW4gY2FzZSBvZiB0dW5uZWxpbmcpIGFy ZSBzdGFja2VkIG9uIHRvcCBvZiBlYWNoIG90aGVyLCBpbi1zaXR1IE9BTQ0KPj4gZGF0YS1yZWNv cmRzIGNvdWxkIGJlIHByZXNlbnQgaW4gZXZlcnkgdHJhbnNwb3J0IHByb3RvY29sIGxheWVyLg0K Pj4gDQo+PiAqIE1hbmFnZW1lbnQgYW5kIGNvbnRyb2wgb2Ygcm9sZSBvZiBub2RlcyBmb3IgaW4t c2l0dSBPQU0gb3BlcmF0aW9uLA0KPj4gZHluYW1pYyBjb250cm9sIG9mIGluLXNpdHUgT0FNIGRh dGEgY29sbGVjdGVkIGluIHRoZSBkYXRhIHJlY29yZHMsIGRhdGENCj4+IGV4cG9ydCBvcHRpbWl6 YXRpb24uDQo+PiANCj4+IA0KPj4gDQo+PiBUaGUgSU9BTSB3b3JraW5nIGdyb3VwIGludGVuZHMg dG8gd29yayBvbiBhbmQgcHVibGlzaDoNCj4+IA0KPj4gKiBEZWZpbml0aW9uIG9mIHRoZSBkYXRh LXR5cGUgZm9ybWF0cyB1c2VkIGluIGluLXNpdHUgT0FNIGFuZCBuYW1lc3BhY2VzDQo+PiBmb3Ig aW4tc2l0dSBPQU0uDQo+PiANCj4+ICogRGVmaW5pdGlvbiBvZiBwcm9jZWR1cmVzIHRoYXQgaW4t c2l0dSBPQU0gZW5hYmxlZCBub2RlcyB3aWxsIHBlcmZvcm0NCj4+IG9uIGRhdGEgdHJhZmZpYyB0 aGF0IGNhcnJpZXMgaW4tc2l0dSBPQU0gaW5mb3JtYXRpb24gKGUuZy4sIGludHJvZHVjaW5nLA0K Pj4gcmVtb3ZpbmcsIHByb2Nlc3NpbmcsIG1vZGlmeWluZywgYW5kIGV4cG9ydGluZyB0aGUgdGVs ZW1ldHJ5IGluZm9ybWF0aW9uDQo+PiBmcm9tIHRoZSBhc3NvY2lhdGVkIGRhdGEgcGFja2V0cyku DQo+PiANCj4+ICogQ29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9uYWwgZGF0YSBtb2RlbHMgZm9y IGNvbnRyb2xsaW5nIGluLXNpdHUgT0FNDQo+PiBkYXRhIGFuZCBvcGVyYXRpb25zLg0KPj4gDQo+ PiBJbi1zaXR1IE9BTSBkYXRhIHJlY29yZHMgY291bGQgYmUgZW1iZWRkZWQgaW50byBhIHZhcmll dHkgb2YgdHJhbnNwb3J0cy4NCj4+IFRoZSB0cmFuc3BvcnRzIGFyZSBleHBlY3RlZCB0byBiZSBk ZWZpbmVkIGluIHRoZSByZXNwZWN0aXZlIHdvcmtpbmcNCj4+IGdyb3VwKHMpIGxpa2UgTlZPMywg U0ZDLCA2bWFuLCBNUExTIGV0YyBpbiBjb25zdWx0YXRpb24gd2l0aCB0aGUgSU9BTQ0KPj4gd29y a2luZyBncm91cCBkb2N1bWVudHMuIElPQU0gV0cgZXhjbHVzaXZlbHkgZm9jdXNlcyBvbiBtZWNo YW5pc21zIHdoaWNoDQo+PiBwaWdneWJhY2sgT0FNLXJlbGF0ZWQgbWV0YWRhdGEgb250byBlbi1y b3V0ZSB0cmFmZmljIGZvciBPQU0gcHVycG9zZXMuDQo+PiBPdGhlciBvbmdvaW5nIE9BTS1yZWxh dGVkIGVmZm9ydHMgaW4gd29ya2luZyBncm91cHMocykgc3VjaCBhcyBNUExTIGFuZA0KPj4gSVBQ TSB0aGF0IGRvIG5vdCBwaWdneWJhY2sgaW5mb3JtYXRpb24gb250byB0aGUgbGl2ZSB1c2VyIGRh dGEgdHJhZmZpYw0KPj4gYXJlIG91dCBvZiBzY29wZSBvZiB0aGUgSU9BTSBXRy4NCj4+IA0KPj4g DQo+PiANCj4+IE1pbGVzdG9uZXMNCj4+IA0KPj4gDQo+PiANCj4+IEFwcmlsIDIwMTggLSBzdWJt aXQgZGF0YSBmb3JtYXQgYW5kIGFzc29jaWF0ZWQgcHJvY2VkdXJlcyBkb2N1bWVudCB0byBJRVNH Lg0KPj4gDQo+PiBNYXJjaCAyMDE4IC0gV0dMQyBmb3IgZGF0YSBmb3JtYXQgYW5kIGFzc29jaWF0 ZWQgcHJvY2VkdXJlcyBkb2N1bWVudC4NCj4+IA0KPj4gQXByaWwgMjAxNyAtIHdvcmtpbmcgZ3Jv dXAgYWRvcHRpb24gb2YgZGF0YSBmb3JtYXQgYW5kIGFzc29jaWF0ZWQNCj4+IHByb2NlZHVyZXMg ZG9jdW1lbnQNCj4+IA0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBJb2FtIG1haWxpbmcgbGlzdA0KPj4gSW9hbUBpZXRmLm9y Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pb2FtDQo+PiANCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElv YW0gbWFpbGluZyBsaXN0DQo+IElvYW1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pb2FtDQoNCg== From nobody Wed Feb 8 07:41:37 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34910129BEA for ; Wed, 8 Feb 2017 07:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, 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=joelhalpern.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 YBotcQ5uYK4e for ; Wed, 8 Feb 2017 07:41:34 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 CDFE3129BD7 for ; Wed, 8 Feb 2017 07:41:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B56EBCA1D11; Wed, 8 Feb 2017 07:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486568494; bh=pbxaYv6N3hWrI3kGyosWXFZvnIsF6J7lV4iCroGAtOs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=j8gVpS8KV4hhxWmoK9yInUavhv//3bFBFSuiChKcjPxnkRCoWhSjisHQlEG+U65jF 7fHWRr4lYRtv+MC9gmFrcMslNFNzKYzzAE3hEZvgG5+XcPX8+thUMFjdw32wFW6TTm R46YwMK8lx47KBkueSA00eHephM7HGyozWCmOxx8= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MBP.home (pool-98-114-54-105.phlapa.fios.verizon.net [98.114.54.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 30746CA1D0B; Wed, 8 Feb 2017 07:41:34 -0800 (PST) To: "Carlos Pignataro (cpignata)" References: <973f34567c5645c3a5ad3f6e0b052d50@IL-EXCH01.marvell.com> <7eb6471e-9830-e369-ce18-9b08a764e3cb@joelhalpern.com> <347D9679-97E1-49D5-B9BB-8FA5C287DC80@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 8 Feb 2017 10:41:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <347D9679-97E1-49D5-B9BB-8FA5C287DC80@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ioam@ietf.org" Subject: Re: [Ioam] Updated Draft Charter X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:41:36 -0000 My concern with the existing sentence is that it reads mor elike "we will find a way around these issues" rather than "these are real world constraints and we have to recognize them." Thus, I like your proposed text better as it recognize constraints and implications, not just problems to be worked around. I think it would be helpful to note these constraints and implications in the section before the list of things to be defined, as that would make it clear that this relates to all of the deliverables. Yours, Joel On 2/8/17 10:31 AM, Carlos Pignataro (cpignata) wrote: > Hi, Joel, > > This is a good point. Most of those considerations are under the > 'Scope of in-situ OAM operation’ heading already, as operational > considerations. > > I would not mind being a tad more prescriptive; perhaps we can add > that “Specifically, the procedures list and evaluate considerations > and constrains imposed due to MTU and packet sizes, as well as domain > boundary implications.” > > Or are you thinking about codifying more specifics in the charter > itself? I think adding such a sentence would close any potential > wedge in the charter, but otherwise can you share more specifics? > > Thanks! > > — Carlos Pignataro, carlos@cisco.com > > “Sometimes I use big words that I do not fully understand, to make > myself sound more photosynthesis." > >> On Feb 8, 2017, at 10:07 AM, Joel M. Halpern >> wrote: >> >> Doesn't there need to be some discussion in the charter of the >> constraints within which this work is to be done? As written, this >> would sem to allow any and all mechanisms, withour\t regard to >> issues such as MTU, complexity of expanding or contracting packets, >> exposure of information across administrative boundaries, or any of >> the other real world constraints which will affect the utility and >> deployability of this work. >> >> Yours, Joel >> >> On 2/7/17 11:17 AM, Tal Mizrahi wrote: >>> Hi, >>> >>> >>> >>> An updated draft charter can be found below. The draft has been >>> updated based on the comments received on the mailing list in the >>> last few days. >>> >>> Many thanks to Shwetha and Frank for ironing out the text. >>> >>> >>> >>> Comments will be welcome. >>> >>> >>> >>> Cheers, >>> >>> Tal. >>> >>> >>> >>> >>> >>> IOAM working group charter >>> >>> >>> >>> In-situ OAM provides real-time telemetry of individual data >>> packets and flows. It is based on telemetry information which is >>> embedded within live data packets. The IOAM WG intends to define >>> data formats and associated procedures for in-situ OAM, including >>> mechanisms for capturing path and path-traversal related >>> information as well as procedures to employ, configure, trigger, >>> and export the embedded telemetry information. >>> >>> >>> >>> The IOAM WG will define the following in-situ OAM components: >>> >>> >>> >>> * Data-records for in-situ OAM to cover path-tracing and path >>> verification information (node-ids, ingress/egress interfaces), >>> timestamps, transit-delay, transit jitter, sequence numbers, >>> application-defined metadata. In-situ OAM data-records are >>> defined using an in-situ OAM namespace. It should be possible to >>> control the information that gets recorded in data-records. >>> >>> * Procedures to add, update, remove, retrieve and export >>> data-records for in-situ OAM to live traffic and active probing. >>> In case of live traffic a classifier to select subset of live >>> traffic for addition, update, removal and retrieval of in-situ >>> OAM data-records. In case of active probing procedure to return >>> the in-situ OAM data records to the source of the probe. >>> >>> * Scope of in-situ OAM operation. In-Situ OAM operations are >>> defined for a specific operational domain. In-situ OAM >>> data-records are added and removed at domain boundaries and >>> updated by nodes within the in-situ OAM domain. Procedure to deal >>> with various challenges in packet forwarding and error handling >>> such as ECMP processing, path MTU and ICMP message handling when >>> in-situ OAM is enabled in an in-situ OAM domain. >>> >>> * Data-records for in-situ OAM are to be defined in a way that >>> makes them independent from the transport protocol used. >>> Data-records for in-situ OAM will need to be embedded into >>> transport protocols such as IPv4, IPv6, VXLAN-GPE, LISP, NSH, >>> SRv6, Geneve. >>> >>> * Procedures and data-records optimized for software dataplane >>> and hardware dataplane implementations of in-situ OAM. >>> >>> * In-situ OAM to support layering. If several transport protocols >>> (e.g. in case of tunneling) are stacked on top of each other, >>> in-situ OAM data-records could be present in every transport >>> protocol layer. >>> >>> * Management and control of role of nodes for in-situ OAM >>> operation, dynamic control of in-situ OAM data collected in the >>> data records, data export optimization. >>> >>> >>> >>> The IOAM working group intends to work on and publish: >>> >>> * Definition of the data-type formats used in in-situ OAM and >>> namespaces for in-situ OAM. >>> >>> * Definition of procedures that in-situ OAM enabled nodes will >>> perform on data traffic that carries in-situ OAM information >>> (e.g., introducing, removing, processing, modifying, and >>> exporting the telemetry information from the associated data >>> packets). >>> >>> * Configuration and operational data models for controlling >>> in-situ OAM data and operations. >>> >>> In-situ OAM data records could be embedded into a variety of >>> transports. The transports are expected to be defined in the >>> respective working group(s) like NVO3, SFC, 6man, MPLS etc in >>> consultation with the IOAM working group documents. IOAM WG >>> exclusively focuses on mechanisms which piggyback OAM-related >>> metadata onto en-route traffic for OAM purposes. Other ongoing >>> OAM-related efforts in working groups(s) such as MPLS and IPPM >>> that do not piggyback information onto the live user data >>> traffic are out of scope of the IOAM WG. >>> >>> >>> >>> Milestones >>> >>> >>> >>> April 2018 - submit data format and associated procedures >>> document to IESG. >>> >>> March 2018 - WGLC for data format and associated procedures >>> document. >>> >>> April 2017 - working group adoption of data format and >>> associated procedures document >>> >>> >>> >>> _______________________________________________ Ioam mailing >>> list Ioam@ietf.org https://www.ietf.org/mailman/listinfo/ioam >>> >> >> _______________________________________________ Ioam mailing list >> Ioam@ietf.org https://www.ietf.org/mailman/listinfo/ioam > From nobody Thu Feb 9 07:57:10 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C95C1296C4; Thu, 9 Feb 2017 07:57:06 -0800 (PST) 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 gHtbzw1aSync; Thu, 9 Feb 2017 07:57:03 -0800 (PST) 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 3CAA5129AF3; Thu, 9 Feb 2017 07:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26956; q=dns/txt; s=iport; t=1486655823; x=1487865423; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZxBpW29uSfkKDoeY7fzy60+y58ERYmiVPOwmy+QBZS0=; b=J8im4g75Eab+vBZcZsROqJ7HVM9CO/LkjxMbHV7bIWrxudhe/+eR//h8 N7xThx4UIqpAlcEof8xBCJmkFegpI0/H5Vs5w+1fQWlq0d23WARZVE1VG DbQq7X+xrg8dRfUUCsHsfPoKtassTVOGvB+f9RV2eWaNtHJA1DIlZXEgb E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAQD0kJxY/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB4NSigiRa4grjSqCDB8BCoJCgzYCGoJQPxgBAgEBAQE?= =?us-ascii?q?BAQFiKIRqAgQBASFEBwsQAgEIJBsDAgICHwYLFBECBA4FiVwDFQ6vfoIlK4cGD?= =?us-ascii?q?YQKAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGTIIFCIJiglGFCS6CMQWJDIxIhWQ?= =?us-ascii?q?4AYZshwyEGYF7jwqILIIIiF4BHzh+TxU8EQGGMHWHcoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.35,137,1484006400"; d="scan'208,217";a="210409755" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Feb 2017 15:57:01 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v19Fv1MY026726 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Feb 2017 15:57:01 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Feb 2017 09:57:01 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 9 Feb 2017 09:57:00 -0600 From: "Alvaro Retana (aretana)" To: Spencer Dawkins at IETF Thread-Topic: Internal WG Review: In-situ OAM (ioam) Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFf5E4AgAECTQA= Date: Thu, 9 Feb 2017 15:57:00 +0000 Message-ID: <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_5EADB2FC91124C6F956DC9B0A7FA405Fciscocom_" MIME-Version: 1.0 Archived-At: Cc: The IAB , "iesg@ietf.org" , "ioam@ietf.org" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 15:57:06 -0000 --_000_5EADB2FC91124C6F956DC9B0A7FA405Fciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3BlbmNlcjoNCg0KSGkhICBJ4oCZbSBjY+KAmWluZyB0aGUgbGlzdCB0byBnZXQgZmVlZGJhY2sg ZnJvbSB0aGVtLg0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMhDQoNCkFsdmFyby4NCg0KT24g Mi84LzE3LCAyOjMyIFBNLCAiaWVzZyBvbiBiZWhhbGYgb2YgU3BlbmNlciBEYXdraW5zIGF0IElF VEYiIDxpZXNnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmllc2ctYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPG1haWx0bzpzcGVuY2Vy ZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpTbywgdGhpbmtpbmcgYWJvdXQgdGhp cyBzb21lIG1vcmUgLi4uDQoNCk1vc3Qgb2Ygd2hhdCBmb2xsb3dzIGlzIHF1ZXN0aW9ucywgc28g eW91IG1heSBiZSBlZHVjYXRpbmcgbWUgaW4gbW9zdCBvZiB0aGUgY2FzZXMsIGluc3RlYWQgb2Yg Y2hhbmdpbmcgdGV4dCBpbiB0aGUgcHJvcG9zZWQgY2hhcnRlci4NCg0KT24gV2VkLCBGZWIgOCwg MjAxNyBhdCAxMjozMiBQTSwgSUVURiBTZWNyZXRhcmlhdCA8aWV0Zi1zZWNyZXRhcmlhdC1yZXBs eUBpZXRmLm9yZzxtYWlsdG86aWV0Zi1zZWNyZXRhcmlhdC1yZXBseUBpZXRmLm9yZz4+IHdyb3Rl Og0KDQoNCkEgbmV3IElFVEYgV0cgaXMgYmVpbmcgY29uc2lkZXJlZCBpbiB0aGUgSUVURi4gVGhl IGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoaXMNCldHIGlzIHByb3ZpZGVkIGJlbG93IGZvciB5b3VyIHJl dmlldyBhbmQgY29tbWVudC4NCg0KUmV2aWV3IHRpbWUgaXMgb25lIHdlZWsuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCkluLXNpdHUgT0FNIChpb2FtKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkN1cnJl bnQgc3RhdHVzOiBQcm9wb3NlZCBXRw0KDQpDaGFpcnM6DQogIFRCRA0KDQpBc3NpZ25lZCBBcmVh IERpcmVjdG9yOg0KICBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hQGNpc2NvLmNvbTxtYWlsdG86YXJl dGFuYUBjaXNjby5jb20+Pg0KDQpSb3V0aW5nIEFyZWEgRGlyZWN0b3JzOg0KICBBbGlhIEF0bGFz IDxha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5jb20+Pg0KICBBbHZhcm8g UmV0YW5hIDxhcmV0YW5hQGNpc2NvLmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+Pg0KICBE ZWJvcmFoIEJydW5nYXJkIDxkYjM1NDZAYXR0LmNvbTxtYWlsdG86ZGIzNTQ2QGF0dC5jb20+Pg0K DQpNYWlsaW5nIGxpc3Q6DQogIEFkZHJlc3M6IGlvYW1AaWV0Zi5vcmc8bWFpbHRvOmlvYW1AaWV0 Zi5vcmc+DQogIFRvIHN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pb2FtDQogIEFyY2hpdmU6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9i cm93c2UvaW9hbS8NCg0KQ2hhcnRlcjogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv Y2hhcnRlci1pZXRmLWlvYW0vDQoNCkluLXNpdHUgT0FNIHByb3ZpZGVzIHJlYWwtdGltZSB0ZWxl bWV0cnkgb2YgaW5kaXZpZHVhbCBkYXRhIHBhY2tldHMgYW5kDQpmbG93cy4NCg0KSXMgaXQgdHJ1 ZSB0byBzYXkgdGhhdCBJbi1zaXR1IE9BTSBwcm92aWRlcyByZWFsLXRpbWUgdGVsZW1ldHJ5IG9m IGluZGl2aWR1YWwgZGF0YSBwYWNrZXRzIGFuZCBmbG93cywgYmFzZWQgb24gaW5mb3JtYXRpb24g ZW1iZWRkZWQgd2l0aGluIGxpdmUgZGF0YSBwYWNrZXRzPw0KDQpJJ20gcmVhZGluZyB0aGUgY3Vy cmVudCB0ZXh0IGFzIHNheWluZyB0aGF0IHRoaXMgY2FuIGRvIE9BTSBmb3IgYW4gaW5kaXZpZHVh bCBwYWNrZXQuIEkgZG9uJ3QgZXZlbiBrbm93IHdoYXQgdGhhdCBtZWFucy4NCg0KSSdtIG5vdCBx dWl0ZSBzdXJlIEkgdW5kZXJzdGFuZCB3aGF0IGEgImxpdmUiIGRhdGEgcGFja2V0IGlzLiBJcyB0 aGUgcG9pbnQgdGhhdCB0aGlzIGlzbid0IGluamVjdGluZyBtZWFzdXJlbWVudCB0cmFmZmljIChz bywgInBhc3NpdmUiLCByYXRoZXIgdGhhbiAiYWN0aXZlIiAtIG9yIGlzIHRoZSB0ZXh0IGNhbGxp bmcgdGhhdCAiYWN0aXZlIHByb2JpbmciKT8gQnV0IEknbSBndWVzc2luZy4NCg0KSXQgaXMgYmFz ZWQgb24gdGVsZW1ldHJ5IGluZm9ybWF0aW9uIHdoaWNoIGlzIGVtYmVkZGVkIHdpdGhpbiBsaXZl DQpkYXRhIHBhY2tldHMuDQoNClRoZXJlJ3MgYSBtZW50aW9uIG9mICJhY3RpdmUgcHJvYmluZyIg ZnVydGhlciBkb3duLiBZb3UgbWlnaHQgd2FudCB0byBicmluZyB0aGF0IHVwIGhlcmUsIHRvIGhl bHAgdGhlIHJlYWRlciB1bmRlcnN0YW5kIHRoZSBzY29wZSBvZiB0aGUgd29yay4NCg0KVGhlIElP QU0gV0cgaW50ZW5kcyB0byBkZWZpbmUgZGF0YSBmb3JtYXRzIGFuZCBhc3NvY2lhdGVkDQpwcm9j ZWR1cmVzIGZvciBpbi1zaXR1IE9BTSwgaW5jbHVkaW5nIG1lY2hhbmlzbXMgZm9yIGNhcHR1cmlu ZyBwYXRoIGFuZA0KcGF0aC10cmF2ZXJzYWwgcmVsYXRlZCBpbmZvcm1hdGlvbiBhcyB3ZWxsIGFz IHByb2NlZHVyZXMgdG8gZW1wbG95LA0KY29uZmlndXJlLCB0cmlnZ2VyLCBhbmQgZXhwb3J0IHRo ZSBlbWJlZGRlZCB0ZWxlbWV0cnkgaW5mb3JtYXRpb24uDQoNClRoZSBJT0FNIFdHIHdpbGwgZGVm aW5lIHRoZSBmb2xsb3dpbmcgaW4tc2l0dSBPQU0gY29tcG9uZW50czoNCg0KKiBEYXRhLXJlY29y ZHMgZm9yIGluLXNpdHUgT0FNIHRvIGNvdmVyIHBhdGgtdHJhY2luZyBhbmQgcGF0aA0KdmVyaWZp Y2F0aW9uIGluZm9ybWF0aW9uIChub2RlLWlkcywgaW5ncmVzcy9lZ3Jlc3MgaW50ZXJmYWNlcyks DQp0aW1lc3RhbXBzLCB0cmFuc2l0LWRlbGF5LCB0cmFuc2l0IGppdHRlciwgc2VxdWVuY2UgbnVt YmVycywNCmFwcGxpY2F0aW9uLWRlZmluZWQgbWV0YWRhdGEuDQoNCklzIHRoaXMgaW50ZW5kZWQg dG8gYmUgYW4gZXhoYXVzdGl2ZSBsaXN0PyBJJ20gZ3Vlc3NpbmcgdGhhdCAiYXBwbGljYXRpb24t ZGVmaW5lZCBtZXRhZGF0YSIgaXMgcHJvYmFibHkgb3Blbi1lbmRlZCAuLi4gYnV0IHdoZXRoZXIg dGhhdCdzIHRydWUgb3Igbm90LCBpcyB0aGUgd29ya2luZyBncm91cCBhbGxvd2VkIHRvIGRlZmlu ZSBpbi1zaXR1IE9BTSB0aGF0IGNvdmVycyBtb3JlIHRoYW4gdGhlc2UgbmFtZWQgcGF0aCBhdHRy aWJ1dGVzPw0KDQpJbi1zaXR1IE9BTSBkYXRhLXJlY29yZHMgYXJlIGRlZmluZWQgdXNpbmcNCmFu IGluLXNpdHUgT0FNIG5hbWVzcGFjZS4gSXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGNvbnRyb2wg dGhlDQppbmZvcm1hdGlvbiB0aGF0IGdldHMgcmVjb3JkZWQgaW4gZGF0YS1yZWNvcmRzLg0KKiBQ cm9jZWR1cmVzIHRvIGFkZCwgdXBkYXRlLCByZW1vdmUsIHJldHJpZXZlIGFuZCBleHBvcnQgZGF0 YS1yZWNvcmRzIGZvcg0KaW4tc2l0dSBPQU0gdG8gbGl2ZSB0cmFmZmljIGFuZCBhY3RpdmUgcHJv YmluZy4gIEluIGNhc2Ugb2YgbGl2ZSB0cmFmZmljDQphIGNsYXNzaWZpZXIgdG8gc2VsZWN0IHN1 YnNldCBvZiBsaXZlIHRyYWZmaWMgZm9yIGFkZGl0aW9uLCB1cGRhdGUsDQpyZW1vdmFsIGFuZCBy ZXRyaWV2YWwgb2YgaW4tc2l0dSBPQU0gZGF0YS1yZWNvcmRzLiBJbiBjYXNlIG9mIGFjdGl2ZQ0K cHJvYmluZyBwcm9jZWR1cmUgdG8gcmV0dXJuIHRoZSBpbi1zaXR1IE9BTSBkYXRhIHJlY29yZHMg dG8gdGhlIHNvdXJjZSBvZg0KdGhlIHByb2JlLg0KKiAgU2NvcGUgb2YgaW4tc2l0dSBPQU0gb3Bl cmF0aW9uLiBJbi1TaXR1IE9BTSBvcGVyYXRpb25zIGFyZSBkZWZpbmVkIGZvcg0KYSBzcGVjaWZp YyBvcGVyYXRpb25hbCBkb21haW4uIEluLXNpdHUgT0FNIGRhdGEtcmVjb3JkcyBhcmUgYWRkZWQg YW5kDQpyZW1vdmVkIGF0IGRvbWFpbiBib3VuZGFyaWVzIGFuZCB1cGRhdGVkIGJ5IG5vZGVzIHdp dGhpbiB0aGUgaW4tc2l0dSBPQU0NCmRvbWFpbi4gUHJvY2VkdXJlIHRvIGRlYWwgd2l0aCB2YXJp b3VzIGNoYWxsZW5nZXMgaW4gcGFja2V0IGZvcndhcmRpbmcNCmFuZCBlcnJvciBoYW5kbGluZyBz dWNoIGFzIEVDTVAgcHJvY2Vzc2luZywgcGF0aCBNVFUgYW5kIElDTVAgbWVzc2FnZQ0KaGFuZGxp bmcgd2hlbiBpbi1zaXR1IE9BTSBpcyBlbmFibGVkIGluIGFuIGluLXNpdHUgT0FNIGRvbWFpbi4N CiogIERhdGEtcmVjb3JkcyBmb3IgaW4tc2l0dSBPQU0gYXJlIHRvIGJlIGRlZmluZWQgaW4gYSB3 YXkgdGhhdCBtYWtlcw0KdGhlbSBpbmRlcGVuZGVudCBmcm9tIHRoZSB0cmFuc3BvcnQgcHJvdG9j b2wgdXNlZC4gRGF0YS1yZWNvcmRzIGZvcg0KaW4tc2l0dSBPQU0gd2lsbCBuZWVkIHRvIGJlIGVt YmVkZGVkIGludG8gdHJhbnNwb3J0IHByb3RvY29scyBzdWNoIGFzDQpJUHY0LCBJUHY2LCBWWExB Ti1HUEUsIExJU1AsIE5TSCwgU1J2NiwgR2VuZXZlLg0KDQpJcyAidHJhbnNwb3J0IHByb3RvY29s IiB0aGUgYmVzdCB0ZXJtIGhlcmU/DQoNCkknbSBub3Qgb2JqZWN0aW5nIHRvIHRoaXMgYmVjYXVz ZSB3ZSdyZSBub3QgdGFsa2luZyBhYm91dCBUQ1AgOi0pIC0gSSdtIGFza2luZyBiZWNhdXNlIEkg ZG9uJ3Qga25vdyB3aGF0IHRoaXMgdGV4dCBpcyB0ZWxsaW5nIG1lIGFib3V0IHRoZXNlIHByb3Rv Y29scy4NCg0KSWYgdGhhdCdzIHRoZSBjbGVhcmVzdCB0ZXJtIGZvciB0aGlzIHByb2JsZW0gZG9t YWluLCB0aGF0J3MgZmluZSwgYnV0IEkgaGFkIHRvIGFzay4NCg0KKiBQcm9jZWR1cmVzIGFuZCBk YXRhLXJlY29yZHMgb3B0aW1pemVkIGZvciBzb2Z0d2FyZSBkYXRhcGxhbmUgYW5kDQpoYXJkd2Fy ZSBkYXRhcGxhbmUgaW1wbGVtZW50YXRpb25zIG9mIGluLXNpdHUgT0FNLg0KKiBJbi1zaXR1IE9B TSB0byBzdXBwb3J0IGxheWVyaW5nLiBJZiBzZXZlcmFsIHRyYW5zcG9ydCBwcm90b2NvbHMgKGUu Zy4NCmluIGNhc2Ugb2YgdHVubmVsaW5nKSBhcmUgc3RhY2tlZCBvbiB0b3Agb2YgZWFjaCBvdGhl ciwgaW4tc2l0dSBPQU0NCmRhdGEtcmVjb3JkcyBjb3VsZCBiZSBwcmVzZW50IGluIGV2ZXJ5IHRy YW5zcG9ydCBwcm90b2NvbCBsYXllci4NCiogTWFuYWdlbWVudCBhbmQgY29udHJvbCBvZiByb2xl IG9mIG5vZGVzIGZvciBpbi1zaXR1IE9BTSBvcGVyYXRpb24sDQpkeW5hbWljIGNvbnRyb2wgb2Yg aW4tc2l0dSBPQU0gZGF0YSBjb2xsZWN0ZWQgaW4gdGhlIGRhdGEgcmVjb3JkcywgZGF0YQ0KZXhw b3J0IG9wdGltaXphdGlvbi4NCg0KVGhlIElPQU0gd29ya2luZyBncm91cCBpbnRlbmRzIHRvIHdv cmsgb24gYW5kIHB1Ymxpc2g6DQoqIERlZmluaXRpb24gb2YgdGhlIGRhdGEtdHlwZSBmb3JtYXRz IHVzZWQgaW4gaW4tc2l0dSBPQU0gYW5kIG5hbWVzcGFjZXMNCmZvciBpbi1zaXR1IE9BTS4NCiog RGVmaW5pdGlvbiBvZiBwcm9jZWR1cmVzIHRoYXQgaW4tc2l0dSBPQU0gZW5hYmxlZCBub2RlcyB3 aWxsIHBlcmZvcm0gb24NCmRhdGEgdHJhZmZpYyB0aGF0IGNhcnJpZXMgaW4tc2l0dSBPQU0gaW5m b3JtYXRpb24gKGUuZy4sIGludHJvZHVjaW5nLA0KcmVtb3ZpbmcsIHByb2Nlc3NpbmcsIG1vZGlm eWluZywgYW5kIGV4cG9ydGluZyB0aGUgdGVsZW1ldHJ5IGluZm9ybWF0aW9uDQpmcm9tIHRoZSBh c3NvY2lhdGVkIGRhdGEgcGFja2V0cykuDQoqIENvbmZpZ3VyYXRpb24gYW5kIG9wZXJhdGlvbmFs IGRhdGEgbW9kZWxzIGZvciBjb250cm9sbGluZyBpbi1zaXR1IE9BTQ0KZGF0YSBhbmQgb3BlcmF0 aW9ucy4NCkluLXNpdHUgT0FNIGRhdGEgcmVjb3JkcyBjb3VsZCBiZSBlbWJlZGRlZCBpbnRvIGEg dmFyaWV0eSBvZiB0cmFuc3BvcnRzLg0KVGhlIHRyYW5zcG9ydHMgYXJlIGV4cGVjdGVkIHRvIGJl IGRlZmluZWQgaW4gdGhlIHJlc3BlY3RpdmUgd29ya2luZw0KZ3JvdXAocykgbGlrZSBOVk8zLCBT RkMsIDZtYW4sIE1QTFMgZXRjIGluIGNvbnN1bHRhdGlvbiB3aXRoIHRoZSBJT0FNDQp3b3JraW5n IGdyb3VwIGRvY3VtZW50cy4gSU9BTSBXRyBleGNsdXNpdmVseSBmb2N1c2VzIG9uIG1lY2hhbmlz bXMgd2hpY2gNCnBpZ2d5YmFjayBPQU0tcmVsYXRlZCBtZXRhZGF0YSBvbnRvIGVuLXJvdXRlIHRy YWZmaWMgZm9yIE9BTSBwdXJwb3Nlcy4NCk90aGVyIG9uZ29pbmcgT0FNLXJlbGF0ZWQgZWZmb3J0 cyBpbiB3b3JraW5nIGdyb3VwcyhzKSBzdWNoIGFzIE1QTFMgYW5kDQpJUFBNIHRoYXQgZG8gbm90 IHBpZ2d5YmFjayBpbmZvcm1hdGlvbiBvbnRvIHRoZSBsaXZlIHVzZXIgZGF0YSB0cmFmZmljDQph cmUgb3V0IG9mIHNjb3BlIG9mIHRoZSBJT0FNIFdHLg0KDQpJdCBtYXkgYmUgdXNlZnVsIHRvIGNh bGwgb3V0IFRTVldHLCBiZWNhdXNlIHRoZXkndmUgYmVlbiBjb25zdWx0aW5nIG9uIHZhcmlvdXMg dHVubmVsaW5nIHByb3RvY29scy4NCg0KSXMgdGhlcmUgYW55IGNvbm5lY3Rpb24gd2l0aCBJUFBN Pw0KDQpNaWxlc3RvbmVzDQoNCkFwcmlsIDIwMTggLSBzdWJtaXQgZGF0YSBmb3JtYXQgYW5kIGFz c29jaWF0ZWQgcHJvY2VkdXJlcyBkb2N1bWVudCB0bw0KSUVTRy4NCk1hcmNoIDIwMTggLSBXR0xD IGZvciBkYXRhIGZvcm1hdCBhbmQgYXNzb2NpYXRlZCBwcm9jZWR1cmVzIGRvY3VtZW50Lg0KQXBy aWwgMjAxNyAtIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gb2YgZGF0YSBmb3JtYXQgYW5kIGFzc29j aWF0ZWQNCnByb2NlZHVyZXMgZG9jdW1lbnQNCg0KTWlsZXN0b25lczoNCg== --_000_5EADB2FC91124C6F956DC9B0A7FA405Fciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5TcGVu Y2VyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkhpISZuYnNwOyBJ4oCZbSBjY+KAmWluZyB0 aGUgbGlzdCB0byBnZXQgZmVlZGJhY2sgZnJvbSB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5B bHZhcm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4t bGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIDIvOC8xNywgMjozMiBQTSwgJnF1b3Q7aWVzZyBvbiBiZWhhbGYgb2YgU3Bl bmNlciBEYXdraW5zIGF0IElFVEYmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnLWJvdW5j ZXNAaWV0Zi5vcmciPmllc2ctYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBo cmVmPSJtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20iPnNwZW5jZXJkYXdraW5z LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIHRoaW5raW5nIGFib3V0IHRo aXMgc29tZSBtb3JlIC4uLiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk1vc3Qgb2Ygd2hhdCBmb2xsb3dzIGlzIHF1ZXN0aW9ucywgc28geW91IG1heSBiZSBl ZHVjYXRpbmcgbWUgaW4gbW9zdCBvZiB0aGUgY2FzZXMsIGluc3RlYWQgb2YgY2hhbmdpbmcgdGV4 dCBpbiB0aGUgcHJvcG9zZWQgY2hhcnRlci48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBXZWQsIEZlYiA4LCAyMDE3IGF0IDEyOjMyIFBNLCBJRVRGIFNlY3JldGFyaWF0 ICZsdDs8YSBocmVmPSJtYWlsdG86aWV0Zi1zZWNyZXRhcmlhdC1yZXBseUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmlldGYtc2VjcmV0YXJpYXQtcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQpBIG5ldyBJRVRGIFdHIGlzIGJlaW5nIGNvbnNpZGVyZWQgaW4gdGhlIElFVEYuIFRo ZSBkcmFmdCBjaGFydGVyIGZvciB0aGlzPGJyPg0KV0cgaXMgcHJvdmlkZWQgYmVsb3cgZm9yIHlv dXIgcmV2aWV3IGFuZCBjb21tZW50Ljxicj4NCjxicj4NClJldmlldyB0aW1lIGlzIG9uZSB3ZWVr Ljxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KPGJyPg0KSW4tc2l0dSBPQU0g KGlvYW0pPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpDdXJyZW50IHN0YXR1czogUHJvcG9zZWQg V0c8YnI+DQo8YnI+DQpDaGFpcnM6PGJyPg0KJm5ic3A7IFRCRDxicj4NCjxicj4NCkFzc2lnbmVk IEFyZWEgRGlyZWN0b3I6PGJyPg0KJm5ic3A7IEFsdmFybyBSZXRhbmEgJmx0OzxhIGhyZWY9Im1h aWx0bzphcmV0YW5hQGNpc2NvLmNvbSI+YXJldGFuYUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxi cj4NClJvdXRpbmcgQXJlYSBEaXJlY3RvcnM6PGJyPg0KJm5ic3A7IEFsaWEgQXRsYXMgJmx0Ozxh IGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+YWthdGxhc0BnbWFpbC5jb208L2E+Jmd0 Ozxicj4NCiZuYnNwOyBBbHZhcm8gUmV0YW5hICZsdDs8YSBocmVmPSJtYWlsdG86YXJldGFuYUBj aXNjby5jb20iPmFyZXRhbmFAY2lzY28uY29tPC9hPiZndDs8YnI+DQombmJzcDsgRGVib3JhaCBC cnVuZ2FyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRiMzU0NkBhdHQuY29tIj5kYjM1NDZAYXR0LmNv bTwvYT4mZ3Q7PGJyPg0KPGJyPg0KTWFpbGluZyBsaXN0Ojxicj4NCiZuYnNwOyBBZGRyZXNzOiA8 YSBocmVmPSJtYWlsdG86aW9hbUBpZXRmLm9yZyI+aW9hbUBpZXRmLm9yZzwvYT48YnI+DQombmJz cDsgVG8gc3Vic2NyaWJlOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lvYW0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaW9hbTwvYT48YnI+DQombmJzcDsgQXJjaGl2ZTogPGEgaHJlZj0iaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9pb2FtLyIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9pb2FtLzwvYT48YnI+ DQo8YnI+DQpDaGFydGVyOiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9jaGFydGVyLWlldGYtaW9hbS8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1pb2FtLzwvYT48YnI+DQo8YnI+DQpJbi1zaXR1 IE9BTSBwcm92aWRlcyByZWFsLXRpbWUgdGVsZW1ldHJ5IG9mIGluZGl2aWR1YWwgZGF0YSBwYWNr ZXRzIGFuZDxicj4NCmZsb3dzLiA8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIGl0IHRydWUgdG8gc2F5IHRoYXQgSW4tc2l0dSBP QU0gcHJvdmlkZXMgcmVhbC10aW1lIHRlbGVtZXRyeSBvZiBpbmRpdmlkdWFsIGRhdGEgcGFja2V0 cyBhbmQgZmxvd3MsIGJhc2VkIG9uIGluZm9ybWF0aW9uIGVtYmVkZGVkIHdpdGhpbiBsaXZlIGRh dGEgcGFja2V0cz8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSdtIHJlYWRpbmcgdGhlIGN1cnJlbnQgdGV4dCBhcyBzYXlpbmcgdGhh dCB0aGlzIGNhbiBkbyBPQU0gZm9yIGFuIGluZGl2aWR1YWwgcGFja2V0LiBJIGRvbid0IGV2ZW4g a25vdyB3aGF0IHRoYXQgbWVhbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3QgcXVpdGUgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCBh ICZxdW90O2xpdmUmcXVvdDsgZGF0YSBwYWNrZXQgaXMuIElzIHRoZSBwb2ludCB0aGF0IHRoaXMg aXNuJ3QgaW5qZWN0aW5nIG1lYXN1cmVtZW50IHRyYWZmaWMgKHNvLCAmcXVvdDtwYXNzaXZlJnF1 b3Q7LCByYXRoZXIgdGhhbiAmcXVvdDthY3RpdmUmcXVvdDsgLSBvciBpcyB0aGUgdGV4dCBjYWxs aW5nIHRoYXQgJnF1b3Q7YWN0aXZlIHByb2JpbmcmcXVvdDspPyBCdXQgSSdtIGd1ZXNzaW5nLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JdCBpcyBiYXNlZCBvbiB0ZWxlbWV0cnkgaW5mb3JtYXRpb24gd2hpY2ggaXMgZW1iZWRkZWQg d2l0aGluIGxpdmU8YnI+DQpkYXRhIHBhY2tldHMuIDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUncyBhIG1lbnRpb24gb2Yg JnF1b3Q7YWN0aXZlIHByb2JpbmcmcXVvdDsgZnVydGhlciBkb3duLiBZb3UgbWlnaHQgd2FudCB0 byBicmluZyB0aGF0IHVwIGhlcmUsIHRvIGhlbHAgdGhlIHJlYWRlciB1bmRlcnN0YW5kIHRoZSBz Y29wZSBvZiB0aGUgd29yay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIElPQU0gV0cgaW50ZW5kcyB0byBkZWZpbmUgZGF0YSBm b3JtYXRzIGFuZCBhc3NvY2lhdGVkPGJyPg0KcHJvY2VkdXJlcyBmb3IgaW4tc2l0dSBPQU0sIGlu Y2x1ZGluZyBtZWNoYW5pc21zIGZvciBjYXB0dXJpbmcgcGF0aCBhbmQ8YnI+DQpwYXRoLXRyYXZl cnNhbCByZWxhdGVkIGluZm9ybWF0aW9uIGFzIHdlbGwgYXMgcHJvY2VkdXJlcyB0byBlbXBsb3ks PGJyPg0KY29uZmlndXJlLCB0cmlnZ2VyLCBhbmQgZXhwb3J0IHRoZSBlbWJlZGRlZCB0ZWxlbWV0 cnkgaW5mb3JtYXRpb24uPGJyPg0KPGJyPg0KVGhlIElPQU0gV0cgd2lsbCBkZWZpbmUgdGhlIGZv bGxvd2luZyBpbi1zaXR1IE9BTSBjb21wb25lbnRzOjxicj4NCjxicj4NCiogRGF0YS1yZWNvcmRz IGZvciBpbi1zaXR1IE9BTSB0byBjb3ZlciBwYXRoLXRyYWNpbmcgYW5kIHBhdGg8YnI+DQp2ZXJp ZmljYXRpb24gaW5mb3JtYXRpb24gKG5vZGUtaWRzLCBpbmdyZXNzL2VncmVzcyBpbnRlcmZhY2Vz KSw8YnI+DQp0aW1lc3RhbXBzLCB0cmFuc2l0LWRlbGF5LCB0cmFuc2l0IGppdHRlciwgc2VxdWVu Y2UgbnVtYmVycyw8YnI+DQphcHBsaWNhdGlvbi1kZWZpbmVkIG1ldGFkYXRhLiA8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHRo aXMgaW50ZW5kZWQgdG8gYmUgYW4gZXhoYXVzdGl2ZSBsaXN0PyBJJ20gZ3Vlc3NpbmcgdGhhdCAm cXVvdDthcHBsaWNhdGlvbi1kZWZpbmVkIG1ldGFkYXRhJnF1b3Q7IGlzIHByb2JhYmx5IG9wZW4t ZW5kZWQgLi4uIGJ1dCB3aGV0aGVyIHRoYXQncyB0cnVlIG9yIG5vdCwgaXMgdGhlIHdvcmtpbmcg Z3JvdXAgYWxsb3dlZCB0byBkZWZpbmUgaW4tc2l0dSBPQU0gdGhhdCBjb3ZlcnMgbW9yZSB0aGFu IHRoZXNlIG5hbWVkDQogcGF0aCBhdHRyaWJ1dGVzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Jbi1zaXR1IE9BTSBkYXRhLXJlY29y ZHMgYXJlIGRlZmluZWQgdXNpbmc8YnI+DQphbiBpbi1zaXR1IE9BTSBuYW1lc3BhY2UuIEl0IHNo b3VsZCBiZSBwb3NzaWJsZSB0byBjb250cm9sIHRoZTxicj4NCmluZm9ybWF0aW9uIHRoYXQgZ2V0 cyByZWNvcmRlZCBpbiBkYXRhLXJlY29yZHMuPGJyPg0KKiBQcm9jZWR1cmVzIHRvIGFkZCwgdXBk YXRlLCByZW1vdmUsIHJldHJpZXZlIGFuZCBleHBvcnQgZGF0YS1yZWNvcmRzIGZvcjxicj4NCmlu LXNpdHUgT0FNIHRvIGxpdmUgdHJhZmZpYyBhbmQgYWN0aXZlIHByb2JpbmcuJm5ic3A7IEluIGNh c2Ugb2YgbGl2ZSB0cmFmZmljPGJyPg0KYSBjbGFzc2lmaWVyIHRvIHNlbGVjdCBzdWJzZXQgb2Yg bGl2ZSB0cmFmZmljIGZvciBhZGRpdGlvbiwgdXBkYXRlLDxicj4NCnJlbW92YWwgYW5kIHJldHJp ZXZhbCBvZiBpbi1zaXR1IE9BTSBkYXRhLXJlY29yZHMuIEluIGNhc2Ugb2YgYWN0aXZlPGJyPg0K cHJvYmluZyBwcm9jZWR1cmUgdG8gcmV0dXJuIHRoZSBpbi1zaXR1IE9BTSBkYXRhIHJlY29yZHMg dG8gdGhlIHNvdXJjZSBvZjxicj4NCnRoZSBwcm9iZS48YnI+DQoqJm5ic3A7IFNjb3BlIG9mIGlu LXNpdHUgT0FNIG9wZXJhdGlvbi4gSW4tU2l0dSBPQU0gb3BlcmF0aW9ucyBhcmUgZGVmaW5lZCBm b3I8YnI+DQphIHNwZWNpZmljIG9wZXJhdGlvbmFsIGRvbWFpbi4gSW4tc2l0dSBPQU0gZGF0YS1y ZWNvcmRzIGFyZSBhZGRlZCBhbmQ8YnI+DQpyZW1vdmVkIGF0IGRvbWFpbiBib3VuZGFyaWVzIGFu ZCB1cGRhdGVkIGJ5IG5vZGVzIHdpdGhpbiB0aGUgaW4tc2l0dSBPQU08YnI+DQpkb21haW4uIFBy b2NlZHVyZSB0byBkZWFsIHdpdGggdmFyaW91cyBjaGFsbGVuZ2VzIGluIHBhY2tldCBmb3J3YXJk aW5nPGJyPg0KYW5kIGVycm9yIGhhbmRsaW5nIHN1Y2ggYXMgRUNNUCBwcm9jZXNzaW5nLCBwYXRo IE1UVSBhbmQgSUNNUCBtZXNzYWdlPGJyPg0KaGFuZGxpbmcgd2hlbiBpbi1zaXR1IE9BTSBpcyBl bmFibGVkIGluIGFuIGluLXNpdHUgT0FNIGRvbWFpbi48YnI+DQoqJm5ic3A7IERhdGEtcmVjb3Jk cyBmb3IgaW4tc2l0dSBPQU0gYXJlIHRvIGJlIGRlZmluZWQgaW4gYSB3YXkgdGhhdCBtYWtlczxi cj4NCnRoZW0gaW5kZXBlbmRlbnQgZnJvbSB0aGUgdHJhbnNwb3J0IHByb3RvY29sIHVzZWQuIERh dGEtcmVjb3JkcyBmb3I8YnI+DQppbi1zaXR1IE9BTSB3aWxsIG5lZWQgdG8gYmUgZW1iZWRkZWQg aW50byB0cmFuc3BvcnQgcHJvdG9jb2xzIHN1Y2ggYXM8YnI+DQpJUHY0LCBJUHY2LCBWWExBTi1H UEUsIExJU1AsIE5TSCwgU1J2NiwgR2VuZXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgJnF1b3Q7dHJhbnNwb3J0IHByb3Rv Y29sJnF1b3Q7IHRoZSBiZXN0IHRlcm0gaGVyZT8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5vdCBvYmplY3RpbmcgdG8gdGhp cyBiZWNhdXNlIHdlJ3JlIG5vdCB0YWxraW5nIGFib3V0IFRDUCA6LSkgLSBJJ20gYXNraW5nIGJl Y2F1c2UgSSBkb24ndCBrbm93IHdoYXQgdGhpcyB0ZXh0IGlzIHRlbGxpbmcgbWUgYWJvdXQgdGhl c2UgcHJvdG9jb2xzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JZiB0aGF0J3MgdGhlIGNsZWFyZXN0IHRlcm0gZm9yIHRoaXMgcHJvYmxlbSBk b21haW4sIHRoYXQncyBmaW5lLCBidXQgSSBoYWQgdG8gYXNrLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFByb2NlZHVyZXMgYW5k IGRhdGEtcmVjb3JkcyBvcHRpbWl6ZWQgZm9yIHNvZnR3YXJlIGRhdGFwbGFuZSBhbmQ8YnI+DQpo YXJkd2FyZSBkYXRhcGxhbmUgaW1wbGVtZW50YXRpb25zIG9mIGluLXNpdHUgT0FNLjxicj4NCiog SW4tc2l0dSBPQU0gdG8gc3VwcG9ydCBsYXllcmluZy4gSWYgc2V2ZXJhbCB0cmFuc3BvcnQgcHJv dG9jb2xzIChlLmcuPGJyPg0KaW4gY2FzZSBvZiB0dW5uZWxpbmcpIGFyZSBzdGFja2VkIG9uIHRv cCBvZiBlYWNoIG90aGVyLCBpbi1zaXR1IE9BTTxicj4NCmRhdGEtcmVjb3JkcyBjb3VsZCBiZSBw cmVzZW50IGluIGV2ZXJ5IHRyYW5zcG9ydCBwcm90b2NvbCBsYXllci48YnI+DQoqIE1hbmFnZW1l bnQgYW5kIGNvbnRyb2wgb2Ygcm9sZSBvZiBub2RlcyBmb3IgaW4tc2l0dSBPQU0gb3BlcmF0aW9u LDxicj4NCmR5bmFtaWMgY29udHJvbCBvZiBpbi1zaXR1IE9BTSBkYXRhIGNvbGxlY3RlZCBpbiB0 aGUgZGF0YSByZWNvcmRzLCBkYXRhPGJyPg0KZXhwb3J0IG9wdGltaXphdGlvbi48YnI+DQo8YnI+ DQpUaGUgSU9BTSB3b3JraW5nIGdyb3VwIGludGVuZHMgdG8gd29yayBvbiBhbmQgcHVibGlzaDo8 YnI+DQoqIERlZmluaXRpb24gb2YgdGhlIGRhdGEtdHlwZSBmb3JtYXRzIHVzZWQgaW4gaW4tc2l0 dSBPQU0gYW5kIG5hbWVzcGFjZXM8YnI+DQpmb3IgaW4tc2l0dSBPQU0uPGJyPg0KKiBEZWZpbml0 aW9uIG9mIHByb2NlZHVyZXMgdGhhdCBpbi1zaXR1IE9BTSBlbmFibGVkIG5vZGVzIHdpbGwgcGVy Zm9ybSBvbjxicj4NCmRhdGEgdHJhZmZpYyB0aGF0IGNhcnJpZXMgaW4tc2l0dSBPQU0gaW5mb3Jt YXRpb24gKGUuZy4sIGludHJvZHVjaW5nLDxicj4NCnJlbW92aW5nLCBwcm9jZXNzaW5nLCBtb2Rp ZnlpbmcsIGFuZCBleHBvcnRpbmcgdGhlIHRlbGVtZXRyeSBpbmZvcm1hdGlvbjxicj4NCmZyb20g dGhlIGFzc29jaWF0ZWQgZGF0YSBwYWNrZXRzKS48YnI+DQoqIENvbmZpZ3VyYXRpb24gYW5kIG9w ZXJhdGlvbmFsIGRhdGEgbW9kZWxzIGZvciBjb250cm9sbGluZyBpbi1zaXR1IE9BTTxicj4NCmRh dGEgYW5kIG9wZXJhdGlvbnMuPGJyPg0KSW4tc2l0dSBPQU0gZGF0YSByZWNvcmRzIGNvdWxkIGJl IGVtYmVkZGVkIGludG8gYSB2YXJpZXR5IG9mIHRyYW5zcG9ydHMuPGJyPg0KVGhlIHRyYW5zcG9y dHMgYXJlIGV4cGVjdGVkIHRvIGJlIGRlZmluZWQgaW4gdGhlIHJlc3BlY3RpdmUgd29ya2luZzxi cj4NCmdyb3VwKHMpIGxpa2UgTlZPMywgU0ZDLCA2bWFuLCBNUExTIGV0YyBpbiBjb25zdWx0YXRp b24gd2l0aCB0aGUgSU9BTTxicj4NCndvcmtpbmcgZ3JvdXAgZG9jdW1lbnRzLiBJT0FNIFdHIGV4 Y2x1c2l2ZWx5IGZvY3VzZXMgb24gbWVjaGFuaXNtcyB3aGljaDxicj4NCnBpZ2d5YmFjayBPQU0t cmVsYXRlZCBtZXRhZGF0YSBvbnRvIGVuLXJvdXRlIHRyYWZmaWMgZm9yIE9BTSBwdXJwb3Nlcy48 YnI+DQpPdGhlciBvbmdvaW5nIE9BTS1yZWxhdGVkIGVmZm9ydHMgaW4gd29ya2luZyBncm91cHMo cykgc3VjaCBhcyBNUExTIGFuZDxicj4NCklQUE0gdGhhdCBkbyBub3QgcGlnZ3liYWNrIGluZm9y bWF0aW9uIG9udG8gdGhlIGxpdmUgdXNlciBkYXRhIHRyYWZmaWM8YnI+DQphcmUgb3V0IG9mIHNj b3BlIG9mIHRoZSBJT0FNIFdHLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgbWF5IGJlIHVzZWZ1bCB0byBjYWxsIG91dCBUU1ZX RywgYmVjYXVzZSB0aGV5J3ZlIGJlZW4gY29uc3VsdGluZyBvbiB2YXJpb3VzIHR1bm5lbGluZyBw cm90b2NvbHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPklzIHRoZXJlIGFueSBjb25uZWN0aW9uIHdpdGggSVBQTT88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlsZXN0 b25lczxicj4NCjxicj4NCkFwcmlsIDIwMTggLSBzdWJtaXQgZGF0YSBmb3JtYXQgYW5kIGFzc29j aWF0ZWQgcHJvY2VkdXJlcyBkb2N1bWVudCB0bzxicj4NCklFU0cuPGJyPg0KTWFyY2ggMjAxOCAt IFdHTEMgZm9yIGRhdGEgZm9ybWF0IGFuZCBhc3NvY2lhdGVkIHByb2NlZHVyZXMgZG9jdW1lbnQu PGJyPg0KQXByaWwgMjAxNyAtIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gb2YgZGF0YSBmb3JtYXQg YW5kIGFzc29jaWF0ZWQ8YnI+DQpwcm9jZWR1cmVzIGRvY3VtZW50PGJyPg0KPGJyPg0KTWlsZXN0 b25lczo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5EADB2FC91124C6F956DC9B0A7FA405Fciscocom_-- From nobody Thu Feb 9 09:18:21 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26328129C1E; Thu, 9 Feb 2017 09:18:20 -0800 (PST) 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=unavailable 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 eQsBTakMepC9; Thu, 9 Feb 2017 09:18:17 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3475129C0D; Thu, 9 Feb 2017 09:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12128; q=dns/txt; s=iport; t=1486660697; x=1487870297; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TZtbkrOTtdYNK2pwFEdgUuHXtWsIaTqQOj5gQr+A3QU=; b=QPyWN6Qn//wIlL48MZpZmdhWiNoIu2lwpbROqfFLnPXOTrWEPT4anEPX pvlUIsHPpbUnT2Ajcq7ukWPgVqdSwB/jzOuMfMZQ22o2rnzeUgnCsG5Sf j9SWzjAFB7a4lVXXqlNNKE3AJw/tHM1ez49wMYKZJFWhYNokhRZlbkkOG o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AQDvo5xY/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FheBEHg1KKCJIJiAyNKoIMHw2CQIM2AhqCUT8YAQIBAQEBAQE?= =?us-ascii?q?BYiiEaQEBAQMBAQEhETMHCwULAgEIGAICCB4CAgIfBgsVEAIEDgWJXAMNCA6wD?= =?us-ascii?q?IIlhzcNhA4BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUGCBYFhgQmCUYIDgwY?= =?us-ascii?q?ugjEFiH4OjEiFZDgBhmyHDIQZgXuFF4lziCwfgWmIXgEfOH5PFTwRAYYwdQGHc?= =?us-ascii?q?YEMAQEB?= X-IronPort-AV: E=Sophos;i="5.35,137,1484006400"; d="scan'208";a="206802021" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 17:18:15 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v19HIEsB009927 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Feb 2017 17:18:15 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Feb 2017 12:18:13 -0500 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; Thu, 9 Feb 2017 12:18:13 -0500 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" Thread-Topic: [Ioam] Internal WG Review: In-situ OAM (ioam) Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFf5E4AgAECTQCAAFm/gA== Date: Thu, 9 Feb 2017 17:18:13 +0000 Message-ID: <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> In-Reply-To: <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.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.117.115.61] Content-Type: text/plain; charset="utf-8" Content-ID: <5945E2813267FA4FB80015EE3D01E116@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: The IAB , "ioam@ietf.org" , Spencer Dawkins at IETF , "iesg@ietf.org" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:18:20 -0000 VGhhbmtzLCBBbHZhcm8uDQoNCkhpLCBTcGVuY2VyLA0KDQpQbGVhc2UgZmluZCBzb21lIGZvbGxv dy11cHMgaW5saW5lLiBMb29rIGZvcndhcmQgdG8gdW5kZXJzdGFuZGluZyBpZiB0aGV5IGNsYXJp ZnksIG9yIHdoYXQgc3BlY2lmaWMgc3VnZ2VzdGlvbnMgY2FuIG1ha2UgdGhlIGNoYXJ0ZXIgdGV4 dCBiZXR0ZXIuDQoNCuKAlA0KQ2FybG9zIFBpZ25hdGFybywgY2FybG9zQGNpc2NvLmNvbQ0KDQri gJxTb21ldGltZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFu ZCwgdG8gbWFrZSBteXNlbGYgc291bmQgbW9yZSBwaG90b3N5bnRoZXNpcy4iDQoNCj4gT24gRmVi IDksIDIwMTcsIGF0IDEwOjU3IEFNLCBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSA8YXJldGFuYUBj aXNjby5jb20+IHdyb3RlOg0KPiANCj4gU3BlbmNlcjoNCj4gIA0KPiBIaSEgIEnigJltIGNj4oCZ aW5nIHRoZSBsaXN0IHRvIGdldCBmZWVkYmFjayBmcm9tIHRoZW0uDQo+ICANCj4gVGhhbmtzIGZv ciB5b3VyIGNvbW1lbnRzIQ0KPiAgDQo+IEFsdmFyby4NCj4gIA0KPj4gT24gMi84LzE3LCAyOjMy IFBNLCAiaWVzZyBvbiBiZWhhbGYgb2YgU3BlbmNlciBEYXdraW5zIGF0IElFVEYiIDxpZXNnLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mc3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+ IHdyb3RlOg0KPj4gIA0KPj4gU28sIHRoaW5raW5nIGFib3V0IHRoaXMgc29tZSBtb3JlIC4uLiAN Cj4+ICANCj4+IE1vc3Qgb2Ygd2hhdCBmb2xsb3dzIGlzIHF1ZXN0aW9ucywgc28geW91IG1heSBi ZSBlZHVjYXRpbmcgbWUgaW4gbW9zdCBvZiB0aGUgY2FzZXMsIGluc3RlYWQgb2YgY2hhbmdpbmcg dGV4dCBpbiB0aGUgcHJvcG9zZWQgY2hhcnRlci4NCj4+ICANCj4+IE9uIFdlZCwgRmViIDgsIDIw MTcgYXQgMTI6MzIgUE0sIElFVEYgU2VjcmV0YXJpYXQgPGlldGYtc2VjcmV0YXJpYXQtcmVwbHlA aWV0Zi5vcmc+IHdyb3RlOg0KPj4+IA0KPj4+IA0KPj4+IEEgbmV3IElFVEYgV0cgaXMgYmVpbmcg Y29uc2lkZXJlZCBpbiB0aGUgSUVURi4gVGhlIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoaXMNCj4+PiBX RyBpcyBwcm92aWRlZCBiZWxvdyBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnQuDQo+Pj4gDQo+ Pj4gUmV2aWV3IHRpbWUgaXMgb25lIHdlZWsuDQo+Pj4gDQo+Pj4gVGhlIElFVEYgU2VjcmV0YXJp YXQNCj4+PiANCj4+PiBJbi1zaXR1IE9BTSAoaW9hbSkNCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+ IEN1cnJlbnQgc3RhdHVzOiBQcm9wb3NlZCBXRw0KPj4+IA0KPj4+IENoYWlyczoNCj4+PiAgIFRC RA0KPj4+IA0KPj4+IEFzc2lnbmVkIEFyZWEgRGlyZWN0b3I6DQo+Pj4gICBBbHZhcm8gUmV0YW5h IDxhcmV0YW5hQGNpc2NvLmNvbT4NCj4+PiANCj4+PiBSb3V0aW5nIEFyZWEgRGlyZWN0b3JzOg0K Pj4+ICAgQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb20+DQo+Pj4gICBBbHZhcm8gUmV0YW5h IDxhcmV0YW5hQGNpc2NvLmNvbT4NCj4+PiAgIERlYm9yYWggQnJ1bmdhcmQgPGRiMzU0NkBhdHQu Y29tPg0KPj4+IA0KPj4+IE1haWxpbmcgbGlzdDoNCj4+PiAgIEFkZHJlc3M6IGlvYW1AaWV0Zi5v cmcNCj4+PiAgIFRvIHN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pb2FtDQo+Pj4gICBBcmNoaXZlOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvYnJvd3NlL2lvYW0vDQo+Pj4gDQo+Pj4gQ2hhcnRlcjogaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLWlvYW0vDQo+Pj4gDQo+Pj4gSW4tc2l0dSBPQU0gcHJv dmlkZXMgcmVhbC10aW1lIHRlbGVtZXRyeSBvZiBpbmRpdmlkdWFsIGRhdGEgcGFja2V0cyBhbmQN Cj4+PiBmbG93cy4gDQo+PiAgDQo+PiBJcyBpdCB0cnVlIHRvIHNheSB0aGF0IEluLXNpdHUgT0FN IHByb3ZpZGVzIHJlYWwtdGltZSB0ZWxlbWV0cnkgb2YgaW5kaXZpZHVhbCBkYXRhIHBhY2tldHMg YW5kIGZsb3dzLCBiYXNlZCBvbiBpbmZvcm1hdGlvbiBlbWJlZGRlZCB3aXRoaW4gbGl2ZSBkYXRh IHBhY2tldHM/IA0KPj4gIA0KDQpJbi1zaXR1IE9BTSByZWNvcmRzIHRlbGVtZXRyeSBpbmZvcm1h dGlvbiBieSBlbWJlZGRpbmcgaXQgaW50byBhY3R1YWwgZGF0YSBwYWNrZXRzIChhcyBvcHBvc2Vk IHRvIHN5bnRoZXRpYyBwcm9iZXMpLiBJbiB0aGF0IGNvbnRleHQsIEnigJlkIHNheSBpdCBpcyB0 cnVlIOKAlCBob3dldmVyLCBzZWUgYmVsb3cuDQoNCj4+IEknbSByZWFkaW5nIHRoZSBjdXJyZW50 IHRleHQgYXMgc2F5aW5nIHRoYXQgdGhpcyBjYW4gZG8gT0FNIGZvciBhbiBpbmRpdmlkdWFsIHBh Y2tldC4gSSBkb24ndCBldmVuIGtub3cgd2hhdCB0aGF0IG1lYW5zLg0KPj4gIA0KPj4gSSdtIG5v dCBxdWl0ZSBzdXJlIEkgdW5kZXJzdGFuZCB3aGF0IGEgImxpdmUiIGRhdGEgcGFja2V0IGlzLiBJ cyB0aGUgcG9pbnQgdGhhdCB0aGlzIGlzbid0IGluamVjdGluZyBtZWFzdXJlbWVudCB0cmFmZmlj IChzbywgInBhc3NpdmUiLCByYXRoZXIgdGhhbiAiYWN0aXZlIiAtIG9yIGlzIHRoZSB0ZXh0IGNh bGxpbmcgdGhhdCAiYWN0aXZlIHByb2JpbmciKT8gQnV0IEknbSBndWVzc2luZy4NCj4+ICANCg0K UGVyaGFwcyDigJxsaXZl4oCdIGlzIHRoZSBkaXN0cmFjdG9yIGhlcmUuIEkgZG8gd29uZGVyIGlm IOKAnGFjdHVhbOKAnSBtaWdodCBtYWtlIGl0IGNsZWFyZXIuDQoNClRoZSBjaGFsbGVuZ2UgaXMg dGhhdCBJbi1zaXR1IE9BTSBpcyBuZWl0aGVyIOKAnGFjdGl2ZeKAnSBub3Qg4oCccGFzc2l2ZeKA nSBtZWFzdXJlbWVudC4NClBhc3NpdmUgbWVhbnMg4oCYc29sZWx5IGJ5IG9ic2VydmF0aW9uIGFu ZCB3aXRob3V0IG1vZGlmaWNhdGlvbiB0byB0aGUgcGFja2V04oCZIChodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLWFjdGl2ZS1wYXNzaXZlLTA2I3NlY3Rpb24tMy42 KS4NCkFjdGl2ZSBtZWFucyDigJhnZW5lcmF0aW5nIChhY2NvbXBhbnlpbmcgLyBzeW50aGV0aWMp IHBhY2tldCBzdHJlYW1z4oCZIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1pcHBtLWFjdGl2ZS1wYXNzaXZlLTA2I3NlY3Rpb24tMy40KS4NCg0KVGh1cywgSW4tc2l0dSBP QU0gaXMgaXRzIG93biBjbGFzcy4NCg0KQmFzZWQgb24gdGhpcywgZG8geW91IGhhdmUgYW5vdGhl ciByZWNvbW1lbmRhdGlvbj8gRG9lcyDigJxhY3R1YWzigJ0gaW5zdGVhZCBvZiDigJxhY3RpdmXi gJ0gbWFrZSBpdCBiZXR0ZXI/DQoNCj4+PiBJdCBpcyBiYXNlZCBvbiB0ZWxlbWV0cnkgaW5mb3Jt YXRpb24gd2hpY2ggaXMgZW1iZWRkZWQgd2l0aGluIGxpdmUNCj4+PiBkYXRhIHBhY2tldHMuIA0K Pj4gIA0KPj4gVGhlcmUncyBhIG1lbnRpb24gb2YgImFjdGl2ZSBwcm9iaW5nIiBmdXJ0aGVyIGRv d24uIFlvdSBtaWdodCB3YW50IHRvIGJyaW5nIHRoYXQgdXAgaGVyZSwgdG8gaGVscCB0aGUgcmVh ZGVyIHVuZGVyc3RhbmQgdGhlIHNjb3BlIG9mIHRoZSB3b3JrLg0KPj4gIA0KDQpTZWUgYWJvdmUu DQoNCj4+PiBUaGUgSU9BTSBXRyBpbnRlbmRzIHRvIGRlZmluZSBkYXRhIGZvcm1hdHMgYW5kIGFz c29jaWF0ZWQNCj4+PiBwcm9jZWR1cmVzIGZvciBpbi1zaXR1IE9BTSwgaW5jbHVkaW5nIG1lY2hh bmlzbXMgZm9yIGNhcHR1cmluZyBwYXRoIGFuZA0KPj4+IHBhdGgtdHJhdmVyc2FsIHJlbGF0ZWQg aW5mb3JtYXRpb24gYXMgd2VsbCBhcyBwcm9jZWR1cmVzIHRvIGVtcGxveSwNCj4+PiBjb25maWd1 cmUsIHRyaWdnZXIsIGFuZCBleHBvcnQgdGhlIGVtYmVkZGVkIHRlbGVtZXRyeSBpbmZvcm1hdGlv bi4NCj4+PiANCj4+PiBUaGUgSU9BTSBXRyB3aWxsIGRlZmluZSB0aGUgZm9sbG93aW5nIGluLXNp dHUgT0FNIGNvbXBvbmVudHM6DQo+Pj4gDQo+Pj4gKiBEYXRhLXJlY29yZHMgZm9yIGluLXNpdHUg T0FNIHRvIGNvdmVyIHBhdGgtdHJhY2luZyBhbmQgcGF0aA0KPj4+IHZlcmlmaWNhdGlvbiBpbmZv cm1hdGlvbiAobm9kZS1pZHMsIGluZ3Jlc3MvZWdyZXNzIGludGVyZmFjZXMpLA0KPj4+IHRpbWVz dGFtcHMsIHRyYW5zaXQtZGVsYXksIHRyYW5zaXQgaml0dGVyLCBzZXF1ZW5jZSBudW1iZXJzLA0K Pj4+IGFwcGxpY2F0aW9uLWRlZmluZWQgbWV0YWRhdGEuIA0KPj4gIA0KPj4gSXMgdGhpcyBpbnRl bmRlZCB0byBiZSBhbiBleGhhdXN0aXZlIGxpc3Q/IEknbSBndWVzc2luZyB0aGF0ICJhcHBsaWNh dGlvbi1kZWZpbmVkIG1ldGFkYXRhIiBpcyBwcm9iYWJseSBvcGVuLWVuZGVkIC4uLiBidXQgd2hl dGhlciB0aGF0J3MgdHJ1ZSBvciBub3QsIGlzIHRoZSB3b3JraW5nIGdyb3VwIGFsbG93ZWQgdG8g ZGVmaW5lIGluLXNpdHUgT0FNIHRoYXQgY292ZXJzIG1vcmUgdGhhbiB0aGVzZSBuYW1lZCBwYXRo IGF0dHJpYnV0ZXM/DQo+PiAgDQoNClRoaXMgaXMgYSBjb21wcmVoZW5zaXZlIGJ1dCBwcm9iYWJs eSBub3QgZnVsbHkgZXhoYXVzdGl2ZSBsaXN0LiBXZSBjb3VsZCBjbGFyaWZ5IHRoaXMuIA0KDQo+ Pj4gSW4tc2l0dSBPQU0gZGF0YS1yZWNvcmRzIGFyZSBkZWZpbmVkIHVzaW5nDQo+Pj4gYW4gaW4t c2l0dSBPQU0gbmFtZXNwYWNlLiBJdCBzaG91bGQgYmUgcG9zc2libGUgdG8gY29udHJvbCB0aGUN Cj4+PiBpbmZvcm1hdGlvbiB0aGF0IGdldHMgcmVjb3JkZWQgaW4gZGF0YS1yZWNvcmRzLg0KPj4+ ICogUHJvY2VkdXJlcyB0byBhZGQsIHVwZGF0ZSwgcmVtb3ZlLCByZXRyaWV2ZSBhbmQgZXhwb3J0 IGRhdGEtcmVjb3JkcyBmb3INCj4+PiBpbi1zaXR1IE9BTSB0byBsaXZlIHRyYWZmaWMgYW5kIGFj dGl2ZSBwcm9iaW5nLiAgSW4gY2FzZSBvZiBsaXZlIHRyYWZmaWMNCj4+PiBhIGNsYXNzaWZpZXIg dG8gc2VsZWN0IHN1YnNldCBvZiBsaXZlIHRyYWZmaWMgZm9yIGFkZGl0aW9uLCB1cGRhdGUsDQo+ Pj4gcmVtb3ZhbCBhbmQgcmV0cmlldmFsIG9mIGluLXNpdHUgT0FNIGRhdGEtcmVjb3Jkcy4gSW4g Y2FzZSBvZiBhY3RpdmUNCj4+PiBwcm9iaW5nIHByb2NlZHVyZSB0byByZXR1cm4gdGhlIGluLXNp dHUgT0FNIGRhdGEgcmVjb3JkcyB0byB0aGUgc291cmNlIG9mDQo+Pj4gdGhlIHByb2JlLg0KPj4+ ICogIFNjb3BlIG9mIGluLXNpdHUgT0FNIG9wZXJhdGlvbi4gSW4tU2l0dSBPQU0gb3BlcmF0aW9u cyBhcmUgZGVmaW5lZCBmb3INCj4+PiBhIHNwZWNpZmljIG9wZXJhdGlvbmFsIGRvbWFpbi4gSW4t c2l0dSBPQU0gZGF0YS1yZWNvcmRzIGFyZSBhZGRlZCBhbmQNCj4+PiByZW1vdmVkIGF0IGRvbWFp biBib3VuZGFyaWVzIGFuZCB1cGRhdGVkIGJ5IG5vZGVzIHdpdGhpbiB0aGUgaW4tc2l0dSBPQU0N Cj4+PiBkb21haW4uIFByb2NlZHVyZSB0byBkZWFsIHdpdGggdmFyaW91cyBjaGFsbGVuZ2VzIGlu IHBhY2tldCBmb3J3YXJkaW5nDQo+Pj4gYW5kIGVycm9yIGhhbmRsaW5nIHN1Y2ggYXMgRUNNUCBw cm9jZXNzaW5nLCBwYXRoIE1UVSBhbmQgSUNNUCBtZXNzYWdlDQo+Pj4gaGFuZGxpbmcgd2hlbiBp bi1zaXR1IE9BTSBpcyBlbmFibGVkIGluIGFuIGluLXNpdHUgT0FNIGRvbWFpbi4NCj4+PiAqICBE YXRhLXJlY29yZHMgZm9yIGluLXNpdHUgT0FNIGFyZSB0byBiZSBkZWZpbmVkIGluIGEgd2F5IHRo YXQgbWFrZXMNCj4+PiB0aGVtIGluZGVwZW5kZW50IGZyb20gdGhlIHRyYW5zcG9ydCBwcm90b2Nv bCB1c2VkLiBEYXRhLXJlY29yZHMgZm9yDQo+Pj4gaW4tc2l0dSBPQU0gd2lsbCBuZWVkIHRvIGJl IGVtYmVkZGVkIGludG8gdHJhbnNwb3J0IHByb3RvY29scyBzdWNoIGFzDQo+Pj4gSVB2NCwgSVB2 NiwgVlhMQU4tR1BFLCBMSVNQLCBOU0gsIFNSdjYsIEdlbmV2ZS4NCj4+ICANCj4+IElzICJ0cmFu c3BvcnQgcHJvdG9jb2wiIHRoZSBiZXN0IHRlcm0gaGVyZT8gDQo+PiAgDQo+PiBJJ20gbm90IG9i amVjdGluZyB0byB0aGlzIGJlY2F1c2Ugd2UncmUgbm90IHRhbGtpbmcgYWJvdXQgVENQIDotKSAt IEknbSBhc2tpbmcgYmVjYXVzZSBJIGRvbid0IGtub3cgd2hhdCB0aGlzIHRleHQgaXMgdGVsbGlu ZyBtZSBhYm91dCB0aGVzZSBwcm90b2NvbHMuDQo+PiAgDQo+PiBJZiB0aGF0J3MgdGhlIGNsZWFy ZXN0IHRlcm0gZm9yIHRoaXMgcHJvYmxlbSBkb21haW4sIHRoYXQncyBmaW5lLCBidXQgSSBoYWQg dG8gYXNrLg0KDQpUaGFua3MgZm9yIGFza2luZy4gQXMgeW91IHN1cm1pc2VkLCB0aGlzIGlzIG5v dCDigJx0cmFuc3BvcnTigJ0gaW4gdGhlIGNvbnRleHQgb2YgdHJhbnNwb3J0LWxheWVyIHByb3Rv Y29scyBhcyBUQ1AuIEluIGZhY3QsIHRoZXNlIHByb3RvY29scyBkbyBub3Qgb3BlcmF0ZSBhdCB0 aGUgc2FtZSBsYXllciAob3IgYXQgYSBkZWZpbmVkIG1vZGVsIGxheWVyKS4NCg0KUGVyaGFwcyDi gJxlbmNhcHN1bGF0aW9uIHByb3RvY29sc+KAnSBpcyBiZXN0Pw0KDQo+PiAgDQo+Pj4gKiBQcm9j ZWR1cmVzIGFuZCBkYXRhLXJlY29yZHMgb3B0aW1pemVkIGZvciBzb2Z0d2FyZSBkYXRhcGxhbmUg YW5kDQo+Pj4gaGFyZHdhcmUgZGF0YXBsYW5lIGltcGxlbWVudGF0aW9ucyBvZiBpbi1zaXR1IE9B TS4NCj4+PiAqIEluLXNpdHUgT0FNIHRvIHN1cHBvcnQgbGF5ZXJpbmcuIElmIHNldmVyYWwgdHJh bnNwb3J0IHByb3RvY29scyAoZS5nLg0KPj4+IGluIGNhc2Ugb2YgdHVubmVsaW5nKSBhcmUgc3Rh Y2tlZCBvbiB0b3Agb2YgZWFjaCBvdGhlciwgaW4tc2l0dSBPQU0NCj4+PiBkYXRhLXJlY29yZHMg Y291bGQgYmUgcHJlc2VudCBpbiBldmVyeSB0cmFuc3BvcnQgcHJvdG9jb2wgbGF5ZXIuDQo+Pj4g KiBNYW5hZ2VtZW50IGFuZCBjb250cm9sIG9mIHJvbGUgb2Ygbm9kZXMgZm9yIGluLXNpdHUgT0FN IG9wZXJhdGlvbiwNCj4+PiBkeW5hbWljIGNvbnRyb2wgb2YgaW4tc2l0dSBPQU0gZGF0YSBjb2xs ZWN0ZWQgaW4gdGhlIGRhdGEgcmVjb3JkcywgZGF0YQ0KPj4+IGV4cG9ydCBvcHRpbWl6YXRpb24u DQo+Pj4gDQo+Pj4gVGhlIElPQU0gd29ya2luZyBncm91cCBpbnRlbmRzIHRvIHdvcmsgb24gYW5k IHB1Ymxpc2g6DQo+Pj4gKiBEZWZpbml0aW9uIG9mIHRoZSBkYXRhLXR5cGUgZm9ybWF0cyB1c2Vk IGluIGluLXNpdHUgT0FNIGFuZCBuYW1lc3BhY2VzDQo+Pj4gZm9yIGluLXNpdHUgT0FNLg0KPj4+ ICogRGVmaW5pdGlvbiBvZiBwcm9jZWR1cmVzIHRoYXQgaW4tc2l0dSBPQU0gZW5hYmxlZCBub2Rl cyB3aWxsIHBlcmZvcm0gb24NCj4+PiBkYXRhIHRyYWZmaWMgdGhhdCBjYXJyaWVzIGluLXNpdHUg T0FNIGluZm9ybWF0aW9uIChlLmcuLCBpbnRyb2R1Y2luZywNCj4+PiByZW1vdmluZywgcHJvY2Vz c2luZywgbW9kaWZ5aW5nLCBhbmQgZXhwb3J0aW5nIHRoZSB0ZWxlbWV0cnkgaW5mb3JtYXRpb24N Cj4+PiBmcm9tIHRoZSBhc3NvY2lhdGVkIGRhdGEgcGFja2V0cykuDQo+Pj4gKiBDb25maWd1cmF0 aW9uIGFuZCBvcGVyYXRpb25hbCBkYXRhIG1vZGVscyBmb3IgY29udHJvbGxpbmcgaW4tc2l0dSBP QU0NCj4+PiBkYXRhIGFuZCBvcGVyYXRpb25zLg0KPj4+IEluLXNpdHUgT0FNIGRhdGEgcmVjb3Jk cyBjb3VsZCBiZSBlbWJlZGRlZCBpbnRvIGEgdmFyaWV0eSBvZiB0cmFuc3BvcnRzLg0KPj4+IFRo ZSB0cmFuc3BvcnRzIGFyZSBleHBlY3RlZCB0byBiZSBkZWZpbmVkIGluIHRoZSByZXNwZWN0aXZl IHdvcmtpbmcNCj4+PiBncm91cChzKSBsaWtlIE5WTzMsIFNGQywgNm1hbiwgTVBMUyBldGMgaW4g Y29uc3VsdGF0aW9uIHdpdGggdGhlIElPQU0NCj4+PiB3b3JraW5nIGdyb3VwIGRvY3VtZW50cy4g SU9BTSBXRyBleGNsdXNpdmVseSBmb2N1c2VzIG9uIG1lY2hhbmlzbXMgd2hpY2gNCj4+PiBwaWdn eWJhY2sgT0FNLXJlbGF0ZWQgbWV0YWRhdGEgb250byBlbi1yb3V0ZSB0cmFmZmljIGZvciBPQU0g cHVycG9zZXMuDQo+Pj4gT3RoZXIgb25nb2luZyBPQU0tcmVsYXRlZCBlZmZvcnRzIGluIHdvcmtp bmcgZ3JvdXBzKHMpIHN1Y2ggYXMgTVBMUyBhbmQNCj4+PiBJUFBNIHRoYXQgZG8gbm90IHBpZ2d5 YmFjayBpbmZvcm1hdGlvbiBvbnRvIHRoZSBsaXZlIHVzZXIgZGF0YSB0cmFmZmljDQo+Pj4gYXJl IG91dCBvZiBzY29wZSBvZiB0aGUgSU9BTSBXRy4NCj4+ICANCj4+IEl0IG1heSBiZSB1c2VmdWwg dG8gY2FsbCBvdXQgVFNWV0csIGJlY2F1c2UgdGhleSd2ZSBiZWVuIGNvbnN1bHRpbmcgb24gdmFy aW91cyB0dW5uZWxpbmcgcHJvdG9jb2xzLiANCj4+ICANCg0KSSBhbSBub3Qgc3VyZSB0aGVyZSBp cyBhIHN0cm9uZyBjb25uZWN0aW9uIHRvIFRTVldHIOKAlCBidXQgb24gdGhlIG90aGVyIGhhbmQs IGl0IG1pZ2h0IG5vdCBodXJ0IHRvIGNhbGwgaXQgb3V0Lg0KDQo+PiBJcyB0aGVyZSBhbnkgY29u bmVjdGlvbiB3aXRoIElQUE0/DQoNClllcywgdGhlcmUgaXMsIGFzIGFscmVhZHkgbWVudGlvbmVk IGFib3ZlLg0KDQpUaGFua3MhDQoNCuKAlCBDYXJsb3MuDQoNCj4+ICANCj4+PiBNaWxlc3RvbmVz DQo+Pj4gDQo+Pj4gQXByaWwgMjAxOCAtIHN1Ym1pdCBkYXRhIGZvcm1hdCBhbmQgYXNzb2NpYXRl ZCBwcm9jZWR1cmVzIGRvY3VtZW50IHRvDQo+Pj4gSUVTRy4NCj4+PiBNYXJjaCAyMDE4IC0gV0dM QyBmb3IgZGF0YSBmb3JtYXQgYW5kIGFzc29jaWF0ZWQgcHJvY2VkdXJlcyBkb2N1bWVudC4NCj4+ PiBBcHJpbCAyMDE3IC0gd29ya2luZyBncm91cCBhZG9wdGlvbiBvZiBkYXRhIGZvcm1hdCBhbmQg YXNzb2NpYXRlZA0KPj4+IHByb2NlZHVyZXMgZG9jdW1lbnQNCj4+PiANCj4+PiBNaWxlc3RvbmVz Og0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJ b2FtIG1haWxpbmcgbGlzdA0KPiBJb2FtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaW9hbQ0KDQo= From nobody Thu Feb 9 10:50:54 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C12A129580; Thu, 9 Feb 2017 10:50:50 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 6uviG0hpTUOT; Thu, 9 Feb 2017 10:50:47 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 9CB291293EE; Thu, 9 Feb 2017 10:50:47 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id v77so28471110wmv.0; Thu, 09 Feb 2017 10:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=a+HqQylT9TLLr6X9YCjFXImLAFbe2JERc1MRAkerrmU=; b=oEUJmEc2sdOAhhPQNdKMOM3nSjo0dkC8IGjo1HTdX46zjQrh+psau4p7ab6KS38uIy Cd6Ilby1VsjCk6waXkZOc+QYLEpnh0sjrNa8/CtDVR1yECV1K3+jmydL74scyPF4jsxr V5AvaleZAtfnnpLjYGPvr0WbmfHiTF4E6U5k0L8fXNOICey0hYbaxVCi8DqZ3+TBNGvi l0DiElBYd1knIWmVdttiwKfM/xF7waMUD7n5fiGMUvtL3MJFo5JWdOR9kWVdE0j201+t WJYtgZiqj0i1QfLGGEzl3BIlTcT4K27esRIqpkkUOk2bG6MhVwMQu2KcD+8Gdpb8gfv9 8Nbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=a+HqQylT9TLLr6X9YCjFXImLAFbe2JERc1MRAkerrmU=; b=ucDxLhC/gSphIj7uOvu8GMdTCF50cC/JKdEvtcsBAmO+OvkW6qnGvEUGrCncUnI6Ee NMe7T2I6gIj9O+H7LLD9jS34Vbq6FgMIM5/SFAwBa2UjPjKtN/cJtOcSmuanwsx8LETo Vi09Y2Y94BWiUenj+IUvivA3A7J9ao2nPlCfELOkYjN4CqkVUFLDlYWUOC9+34yiaq+6 vEPNCwStOo5L4hjFaekaq8mgX0I/240YbNJ6uyDrLxh+OIhLoxOSadNaJwZdemrp2TtZ OJe+rtg3K1X43JNUHGi+H2YKXLiQN56tob6lQdPXBHcQlqOnrNlp8CKKUGbGW5dcNEWE Ey2g== X-Gm-Message-State: AMke39myr33HyZfqjjSWB51NDXs9PG2VZOrPvY0X0TKS7x38h+iF0ywkYpnvAHXHC6ZPsg== X-Received: by 10.28.12.68 with SMTP id 65mr24241340wmm.100.1486666245777; Thu, 09 Feb 2017 10:50:45 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id y80sm19985483wrb.12.2017.02.09.10.50.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 10:50:45 -0800 (PST) To: "Carlos Pignataro (cpignata)" , "Alvaro Retana (aretana)" References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> From: Stewart Bryant Message-ID: <4f16e222-97e4-6f87-e1a3-79115db8f355@gmail.com> Date: Thu, 9 Feb 2017 18:50:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "iesg@ietf.org" , The IAB , Spencer Dawkins at IETF , "ioam@ietf.org" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 18:50:50 -0000 On 09/02/2017 17:18, Carlos Pignataro (cpignata) wrote: > Passive means ‘solely by observation and without modification to the packet’ (https://tools.ietf.org/html/draft-ietf-ippm-active-passive-06#section-3.6). Carlos, that is not quit where we are going with passive. We use packet marking to batch the packets for loss measurement, and we are planning to trigger delay/jitter measurement through marking. As you know marking is much easier in MPLS that IP. I think the key distinguisher is really that in-situ is about embedding OAM meta-data in user data traffic. - Stewart From nobody Thu Feb 9 11:31:09 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F2F129C71; Thu, 9 Feb 2017 11:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, 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 nNFHE-3a3HWh; Thu, 9 Feb 2017 11:31:00 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA38127077; Thu, 9 Feb 2017 11:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3064; q=dns/txt; s=iport; t=1486668659; x=1487878259; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lly+WVQR8WXCfDYznSBPOlS3TyOXG9p6R7+6ITjbFhE=; b=SyQJz0/1u0LndQ8JZeHC/PDHLGjqCR8JWCjMscGCXQX+9U8lo6DM9AXx d3NRd6fnJgy7CqXHt6fUU8DQl/+1B7eqPg/HSwZTEKBZy0AT3vqN3sN12 f2qdV3EEnSCvYG4exR/w7rPIxqHcZw+5ouy00Z9jOWKjFnvhUc2NPnMKe M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkBQAkwpxY/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHg1Kbcx+IDI0qgg0shXYCGoJRQBcBAgEBAQEBAQFiKIR?= =?us-ascii?q?pAQEBAwEjEUUFCwIBCBgCAiYCAgIfERUQAgQOBYlcAw0IDrAIgiWHOg2EDgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgQuFQYIFCIJiglGCAxeCby6CMQWVVIVkOgG?= =?us-ascii?q?GbocMhBmBe4UXiXOKNYhfASABNn5PFU0BhjB1AYhugQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,137,1484006400"; d="scan'208";a="178805268" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 19:30:59 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v19JUwoC001356 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Feb 2017 19:30:58 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Feb 2017 14:30:57 -0500 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; Thu, 9 Feb 2017 14:30:57 -0500 From: "Carlos Pignataro (cpignata)" To: Stewart Bryant Thread-Topic: [Ioam] Internal WG Review: In-situ OAM (ioam) Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFf5E4AgAECTQCAAFm/gIAAGdcAgAALP4A= Date: Thu, 9 Feb 2017 19:30:57 +0000 Message-ID: References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <4f16e222-97e4-6f87-e1a3-79115db8f355@gmail.com> In-Reply-To: <4f16e222-97e4-6f87-e1a3-79115db8f355@gmail.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.117.115.61] Content-Type: text/plain; charset="utf-8" Content-ID: <32829AB4B06BFC49A6DCD7545E44386C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "iesg@ietf.org" , "Alvaro Retana \(aretana\)" , The IAB , Spencer Dawkins at IETF , "ioam@ietf.org" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 19:31:01 -0000 SGksIFN0ZXdhcnQsDQoNCk1hbnkgdGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHBsZWFzZSBzZWUg aW5saW5lLg0KDQo+IE9uIEZlYiA5LCAyMDE3LCBhdCAxOjUwIFBNLCBTdGV3YXJ0IEJyeWFudCA8 c3Rld2FydC5icnlhbnRAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IA0KPiANCj4gT24gMDkvMDIv MjAxNyAxNzoxOCwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIHdyb3RlOg0KPj4gUGFzc2l2 ZSBtZWFucyDigJhzb2xlbHkgYnkgb2JzZXJ2YXRpb24gYW5kIHdpdGhvdXQgbW9kaWZpY2F0aW9u IHRvIHRoZSBwYWNrZXTigJkgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWlwcG0tYWN0aXZlLXBhc3NpdmUtMDYjc2VjdGlvbi0zLjYpLg0KPiANCj4gQ2FybG9zLCB0aGF0 IGlzIG5vdCBxdWl0IHdoZXJlIHdlIGFyZSBnb2luZyB3aXRoIHBhc3NpdmUuIFdlIHVzZSBwYWNr ZXQgbWFya2luZyB0byBiYXRjaCB0aGUgcGFja2V0cyBmb3IgbG9zcyBtZWFzdXJlbWVudCwgYW5k IHdlIGFyZSBwbGFubmluZyB0byB0cmlnZ2VyIGRlbGF5L2ppdHRlciBtZWFzdXJlbWVudCB0aHJv dWdoIG1hcmtpbmcuDQo+IA0KDQpJ4oCZbGwgZm9sbG93IGRvd24gdGhpcyB0YW5nZW50IGZvciBh IGJpdC4gDQoNCkkgdW5kZXJzdGFuZCBhbmQgYXMgeW91IGtub3cgSeKAmW0gd2VsbCBhd2FyZSBv ZiB0aGUgKGFsdGVybmF0ZSkgcGFja2V0IG1hcmtpbmcgdGVjaG5pcXVlcyBhbmQgZGlmZmVyZW50 IG1ldGhvZHMuDQoNCkhvd2V2ZXIsIHRoZSAqY3VycmVudCogZGVmaW5pdGlvbiBpcyBxdWl0ZSB1 bmFtYmlndW91czoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc3OTkjc2VjdGlv bi0zLjYNCuKAnA0KMy42LiAgUGFzc2l2ZSBNZXRob2RzDQoNCiAgIFBhc3NpdmUgTWV0aG9kcyBv ZiBNZWFzdXJlbWVudCBhcmU6DQoNCiAgIG8gIGJhc2VkIHNvbGVseSBvbiBvYnNlcnZhdGlvbnMg b2YgYW4gdW5kaXN0dXJiZWQgYW5kIHVubW9kaWZpZWQNCiAgICAgIHBhY2tldCBzdHJlYW0gb2Yg aW50ZXJlc3QgKGluIG90aGVyIHdvcmRzLCB0aGUgbWV0aG9kIG9mDQogICAgICBtZWFzdXJlbWVu dCBNVVNUIE5PVCBhZGQsIGNoYW5nZSwgb3IgcmVtb3ZlIHBhY2tldHMgb3IgZmllbGRzIG9yDQog ICAgICBjaGFuZ2UgZmllbGQgdmFsdWVzIGFueXdoZXJlIGFsb25nIHRoZSBwYXRoKS4NCuKAnA0K DQpTaW5jZSBib3RoIHRob3NlIGRhdGFwb2ludHMgYXJlIHJvb3RlZCBpbiBJUFBNLCBJ4oCZZCBz dWdnZXN0IHdvcmtpbmcgdGhyb3VnaCB0aGUgZGVmaW5pdGlvbnMgb24gSVBQTSBhbmQgaG93IG1h cmtpbmcgZml0cyAoc2luY2UgaXQgaXMgbm90IG9ubHkgb24gb2JzZXJ2YXRpb24gcG9pbnRzKQ0K DQpOb3csIGJyaW5naW5nIHRoaXMgYmFjayB0byB0aGUgcmVsZXZhbmNlIG9mIHRoZSBJbi1zaXR1 IE9BTSAoaW9hbSkgY2hhcnRlciwgbXkgb25seSBwb2ludCBpcyB0aGF0IEluLXNpdHUgT0FNIGlz IG5laXRoZXIgcGFzc2l2ZSBub3IgYWN0aXZlLg0KDQo+IEFzIHlvdSBrbm93IG1hcmtpbmcgaXMg bXVjaCBlYXNpZXIgaW4gTVBMUyB0aGF0IElQLg0KPiANCj4gSSB0aGluayB0aGUga2V5IGRpc3Rp bmd1aXNoZXIgaXMgcmVhbGx5IHRoYXQgaW4tc2l0dSBpcyBhYm91dCBlbWJlZGRpbmcgT0FNIG1l dGEtZGF0YSBpbiB1c2VyIGRhdGEgdHJhZmZpYy4NCg0KVGhpcyBpcyBhIGdvb2QgcG9pbnQuDQoN CkkgYWdyZWUuDQoNCkkgYmVsaWV2ZSB0aGlzIGlzIGFscmVhZHkgY2xlYXIgaW4gdGhlIGNoYXJ0 ZXIsIGFsbCB0aGUgd2F5IGZyb20gdGhlIHZlcnkgZmlyc3Qgc2VudGVuY2U6DQoNCuKAnCBJdCBp cyBiYXNlZCBvbiB0ZWxlbWV0cnkgaW5mb3JtYXRpb24gd2hpY2ggaXMgZW1iZWRkZWQgd2l0aGlu IGxpdmUgZGF0YSBwYWNrZXRzLuKAnQ0KDQpEbyB5b3UgYmVsaWV2ZSB0aGlzIGlzIG5vdCBjbGVh ciBpbiB0aGUgY2hhcnRlcj8gRG8geW91IGhhdmUgc3BlY2lmaWMgc3VnZ2VzdGlvbnMgb3IgY29u Y3JldGUgcmVjb21tZW5kYXRpb25zIHRoYXQgY2FuIGltcHJvdmUgdGhlIGNoYXJ0ZXIgdGV4dD8N Cg0KVGhhbmtzIQ0KDQo+IA0KPiAtIFN0ZXdhcnQNCg0KDQrigJQNCkNhcmxvcyBQaWduYXRhcm8s IGNhcmxvc0BjaXNjby5jb20NCg0K4oCcU29tZXRpbWVzIEkgdXNlIGJpZyB3b3JkcyB0aGF0IEkg ZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1ha2UgbXlzZWxmIHNvdW5kIG1vcmUgcGhvdG9z eW50aGVzaXMuIg0KDQo= From nobody Thu Feb 9 14:38:54 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC541295F6; Thu, 9 Feb 2017 14:38:49 -0800 (PST) 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 IMZ70a0Gxmh5; Thu, 9 Feb 2017 14:38:48 -0800 (PST) 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 ABEF61294D4; Thu, 9 Feb 2017 14:38:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34770; q=dns/txt; s=iport; t=1486679927; x=1487889527; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UDuxifdAEgJ2ZxMNlNpn+FHLy2k+q1Fgtsu8vrMg3qQ=; b=EIuvvZea8fReiHMGDmpPFiDjcXGz6vo2nur/IoR9jqaqZzGq4b+l+Mtn l4vD5HkAzWXK1Szzp2IRp9qsHS5DYDX0qsaMibQg54PfpielvZrlDnevr VXuJVRBuzkC3XTJkzCEEnvhHtsW8XFldvHEXMswOgh0Bi9N2GNMM2G7px U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgBC7pxY/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm84KmGBCQeDUooIkWsfiAyNKoINHwEKgkKDNgIaglI/GAECAQE?= =?us-ascii?q?BAQEBAWIohGoCBAEBIUQHCxACAQgkFAcDAgICHwYLFBECBAENBYlcAxUOsAmCJ?= =?us-ascii?q?SuHDw2EDgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhkyCBQiCYoJRgWYBATKCby6?= =?us-ascii?q?CMQWJDIxIhWQ6AYZuhwyEGQqBcY8KiCyCCYhfAR84fk8VPBEBhjB1AYdNgSGBD?= =?us-ascii?q?AEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,138,1484006400"; d="scan'208,217";a="382847160" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Feb 2017 22:38:46 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v19Mck1f007797 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Feb 2017 22:38:46 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Feb 2017 16:38:45 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 9 Feb 2017 16:38:45 -0600 From: "Alvaro Retana (aretana)" To: Stephen Farrell , "ioam@ietf.org" Thread-Topic: Internal WG Review: In-situ OAM (ioam) Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFhgq0A///ULoA= Date: Thu, 9 Feb 2017 22:38:45 +0000 Message-ID: References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <87206d4b-9b2c-f44c-754c-628e8c8e8887@cs.tcd.ie> In-Reply-To: <87206d4b-9b2c-f44c-754c-628e8c8e8887@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_E23424A5D78F4680B54234CD6BC59862ciscocom_" MIME-Version: 1.0 Archived-At: Cc: The IAB , "iesg@ietf.org" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 22:38:49 -0000 --_000_E23424A5D78F4680B54234CD6BC59862ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3RlcGhlbjoNCg0KSGkhDQoNCkkgdGhpbmsgdHJpY2t5LCBidXQgaW1wb3J0YW50LiAgSeKAmW0g Y2PigJlpbmcgdGhlIGxpc3QgdG8gZ2V0IHRoZSBhbnN3ZXJzIHRoZXJlLg0KDQpUbyB5b3VyIHNl Y29uZCBxdWVzdGlvbi4gIFllcywgdGhlcmUgY2xlYXJseSBpcyBhbiBleHBlY3RhdGlvbiBvbiB0 aGUgb3V0Y29tZSwgaWYgSVB2NiBpcyB1c2VkIGFzIGFuIGVuY2Fwc3VsYXRpbmcgcHJvdG9jb2wu ICBCdXQgdGhhdCBpcyBub3QgdGhlIG9ubHkgYXBwbGljYXRpb24uDQoNClRoYW5rcyENCg0KQWx2 YXJvLg0KDQpPbiAyLzkvMTcsIDM6MTUgUE0sICJpZXNnIG9uIGJlaGFsZiBvZiBTdGVwaGVuIEZh cnJlbGwiIDxpZXNnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmllc2ctYm91bmNlc0BpZXRmLm9y Zz4gb24gYmVoYWxmIG9mIHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8bWFpbHRvOnN0ZXBoZW4u ZmFycmVsbEBjcy50Y2QuaWU+PiB3cm90ZToNCg0KDQpIaXlhLA0KDQpJIGhhdmUgdHdvIHBvc3Np Ymx5IHRyaWNreSBxdWVzdGlvbnMgYWJvdXQgdGhpczoNCg0KMSkgSSdtIHN1cmUgdGhlcmUgYXJl IGdvb2QgdGhpbmdzIG9uZSBjYW4gZG8gd2l0aCBzdWNoDQptYXJraW5nLCBidXQgaXQgaXMgdmVy eSB1bmNsZWFyIHRvIG1lIGhvdyB0aGlzIHByb3Bvc2FsDQpkb2Vzbid0IGFsc28gZmFsbCBhZm91 bCBvZiBhbGwgdGhlIHByaXZhY3kgZG93bnNpZGVzIG9mDQp0aGUgU1BVRC9QTFVTIHByb3Bvc2Fs LiBNeSB1bmRlcnN0YW5kaW5nIG9mIHRob3NlIHByaXZhY3kNCmRvd25zaWRlcyB3YXMgdGhhdCBh bnkgZ2VuZXJpYy9leHRlbnNpYmxlIG1hcmtpbmcgc2NoZW1lDQood2hldGhlciBvZiBwYWNrZXRz IG9yIHRyYW5zcG9ydCBjb25uZWN0aW9ucy9mbG93cykgY291bGQNCmVhc2lseSBiZSBhYnVzZWQg aW4gbWFueSBwcml2YWN5IHVuZnJpZW5kbHkgd2F5cy4gTm90ZQ0KdGhhdCBJJ20gbm90IGNsYWlt aW5nIHRoZXJlIGlzIElFVEYgY29uc2Vuc3VzIG9uIHRoYXQNCmJ1dCBJIGRvIGNsYWltIGl0IHdh cyBhIHNpZ25pZmljYW50IGlzc3VlIGZvciBTUFVEL1BMVVMNCmFuZCB3b3VsZCBsaWtlIHRvIGtu b3cgd2h5IChhbmQgaG9wZSkgaXQgaXMgbm90IGFuIGlzc3VlDQpoZXJlLiBDYW4gc29tZW9uZSBo ZWxwIG1lIHVuZGVyc3RhbmQgd2hhdCdzIGRpZmZlcmVudCBoZXJlDQpzbyB3ZSBhdm9pZCB0aGF0 IHNhbWUga2luZCBvZiBtZWdhLWRlYmF0ZT8NCg0KMikgVGhlcmUgaXMgYW4gb25nb2luZyBhbmQg c2VlbWluZ2x5IHZlcnkgaGFyZCB0byByZXNvbHZlDQpkaXNjdXNzaW9uIFsxXSBvbiBpZXRmQGll dGYub3JnPG1haWx0bzppZXRmQGlldGYub3JnPiBpbiB3aGljaCBhIGRyYWZ0IHJlbGF0ZWQgdG8N CnRoaXMgcHJvcG9zYWwgaGFzIGJlZW4gcXVvdGVkIFsyXSBhcyBldmlkZW5jZSBvbiBvbmUgc2lk ZQ0Kb2YgdGhlIGFyZ3VtZW50LiBJJ20gbm90IGNsZWFyIHRoYXQgd2Ugc2hvdWxkIGdvIGFoZWFk IHdpdGgNCnRoaXMgY2hhcnRlciBiZWZvcmUgd2UgaGF2ZSBlc3RhYmxpc2hlZCBJRVRGIGNvbnNl bnN1cw0Kb25lIHdheSBvciBhbm90aGVyIGFib3V0IHdoYXQgd2UgdGhpbmsgYWJvdXQgWzFdIChi eSB3aGljaA0KSSBzcGVjaWZpY2FsbHkgbWVhbiB0aGUgaXNzdWUgb2YgaGVhZGVycyBiZWluZyBw cm9jZXNzZWQNCmF3YXkgZnJvbSB0aGUgZW5kcG9pbnRzKS4gSWYgSSdtIHJpZ2h0IHRoYXQgdGhl c2UgYXJlDQpyZWxhdGVkIChhbmQgaXQncyBwb3NzaWJsZSBJJ20gZW50aXJlbHkgd3Jvbmc7LSkg dGhlbiBJDQpndWVzcyBkZXBlbmRpbmcgb24gdGhlIG91dGNvbWUgb2YgWzFdIHRoYXQnZCBlaXRo ZXIgbWVhbg0KYSBzaG9ydCBkZWxheSBmb3IgdGhpcywgb3IgZWxzZSBhIG5lZWQgZm9yIHNvbWUg bWFqb3INCmNoYW5nZSBhbmQgdGhhdCByaXNrIHdvdWxkIHNlZW0gdG8gbWUgdG8ganVzdGlmeSBu b3QNCmZvcmdpbmcgYWhlYWQgd2l0aCB0aGlzIGp1c3QgeWV0LiBTbyB0aGUgcXVlc3Rpb24gaXM6 DQphbSBJIHJpZ2h0IHRoYXQgdGhpcyBwcm9wb3NhbCBhc3N1bWVzIG9uZSBvdXRjb21lIG9mDQp0 aGUgZGlzY3Vzc2lvbiBhYm91dCBoZWFkZXIgcHJvY2Vzc2luZyBpbiBbMV0/DQoNCkNoZWVycywN ClMuDQoNClBTOiBJJ20gZmluZSB0byBhc2sgdGhlc2UgdHdvIHF1ZXN0aW9ucyBpbiBhIGJhbGxv dCBpZiB0aGF0J3MNCmJldHRlci4gQnV0IGF0IHRoZSBtb21lbnQgdGhhdCdkIGxpa2VseSBiZSBh IEJMT0NLIGJhbGxvdA0Kc28gSSB3YW50ZWQgdG8gY2hlY2sgZmlyc3QgaWYgSSdtIG9mZiBiYXNl LCBhcyBoYXBwZW5zIG5vdw0KYW5kIHRoZW46LSkNCg0KDQpbMV0gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9pZXRmL2N1cnJlbnQvbXNnMTAwOTYwLmh0bWwNClsyXSBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lldGYvY3VycmVudC9tc2cxMDEwMTIu aHRtbA0KDQoNCk9uIDA4LzAyLzE3IDE4OjMyLCBJRVRGIFNlY3JldGFyaWF0IHdyb3RlOg0KQSBu ZXcgSUVURiBXRyBpcyBiZWluZyBjb25zaWRlcmVkIGluIHRoZSBJRVRGLiBUaGUgZHJhZnQgY2hh cnRlciBmb3IgdGhpcw0KV0cgaXMgcHJvdmlkZWQgYmVsb3cgZm9yIHlvdXIgcmV2aWV3IGFuZCBj b21tZW50Lg0KUmV2aWV3IHRpbWUgaXMgb25lIHdlZWsuDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K SW4tc2l0dSBPQU0gKGlvYW0pDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ3VycmVudCBzdGF0dXM6IFByb3Bv c2VkIFdHDQpDaGFpcnM6DQogICBUQkQNCkFzc2lnbmVkIEFyZWEgRGlyZWN0b3I6DQogICBBbHZh cm8gUmV0YW5hIDxhcmV0YW5hQGNpc2NvLmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+Pg0K Um91dGluZyBBcmVhIERpcmVjdG9yczoNCiAgIEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29t PG1haWx0bzpha2F0bGFzQGdtYWlsLmNvbT4+DQogICBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hQGNp c2NvLmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+Pg0KICAgRGVib3JhaCBCcnVuZ2FyZCA8 ZGIzNTQ2QGF0dC5jb208bWFpbHRvOmRiMzU0NkBhdHQuY29tPj4NCg0KTWFpbGluZyBsaXN0Og0K ICAgQWRkcmVzczogaW9hbUBpZXRmLm9yZzxtYWlsdG86aW9hbUBpZXRmLm9yZz4NCiAgIFRvIHN1 YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pb2FtDQogICBB cmNoaXZlOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL2lvYW0vDQpD aGFydGVyOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtaW9h bS8NCkluLXNpdHUgT0FNIHByb3ZpZGVzIHJlYWwtdGltZSB0ZWxlbWV0cnkgb2YgaW5kaXZpZHVh bCBkYXRhIHBhY2tldHMgYW5kDQpmbG93cy4gSXQgaXMgYmFzZWQgb24gdGVsZW1ldHJ5IGluZm9y bWF0aW9uIHdoaWNoIGlzIGVtYmVkZGVkIHdpdGhpbiBsaXZlDQpkYXRhIHBhY2tldHMuIFRoZSBJ T0FNIFdHIGludGVuZHMgdG8gZGVmaW5lIGRhdGEgZm9ybWF0cyBhbmQgYXNzb2NpYXRlZA0KcHJv Y2VkdXJlcyBmb3IgaW4tc2l0dSBPQU0sIGluY2x1ZGluZyBtZWNoYW5pc21zIGZvciBjYXB0dXJp bmcgcGF0aCBhbmQNCnBhdGgtdHJhdmVyc2FsIHJlbGF0ZWQgaW5mb3JtYXRpb24gYXMgd2VsbCBh cyBwcm9jZWR1cmVzIHRvIGVtcGxveSwNCmNvbmZpZ3VyZSwgdHJpZ2dlciwgYW5kIGV4cG9ydCB0 aGUgZW1iZWRkZWQgdGVsZW1ldHJ5IGluZm9ybWF0aW9uLg0KDQpUaGUgSU9BTSBXRyB3aWxsIGRl ZmluZSB0aGUgZm9sbG93aW5nIGluLXNpdHUgT0FNIGNvbXBvbmVudHM6DQoNCiogRGF0YS1yZWNv cmRzIGZvciBpbi1zaXR1IE9BTSB0byBjb3ZlciBwYXRoLXRyYWNpbmcgYW5kIHBhdGgNCnZlcmlm aWNhdGlvbiBpbmZvcm1hdGlvbiAobm9kZS1pZHMsIGluZ3Jlc3MvZWdyZXNzIGludGVyZmFjZXMp LA0KdGltZXN0YW1wcywgdHJhbnNpdC1kZWxheSwgdHJhbnNpdCBqaXR0ZXIsIHNlcXVlbmNlIG51 bWJlcnMsDQphcHBsaWNhdGlvbi1kZWZpbmVkIG1ldGFkYXRhLiBJbi1zaXR1IE9BTSBkYXRhLXJl Y29yZHMgYXJlIGRlZmluZWQgdXNpbmcNCmFuIGluLXNpdHUgT0FNIG5hbWVzcGFjZS4gSXQgc2hv dWxkIGJlIHBvc3NpYmxlIHRvIGNvbnRyb2wgdGhlDQppbmZvcm1hdGlvbiB0aGF0IGdldHMgcmVj b3JkZWQgaW4gZGF0YS1yZWNvcmRzLg0KKiBQcm9jZWR1cmVzIHRvIGFkZCwgdXBkYXRlLCByZW1v dmUsIHJldHJpZXZlIGFuZCBleHBvcnQgZGF0YS1yZWNvcmRzIGZvcg0KaW4tc2l0dSBPQU0gdG8g bGl2ZSB0cmFmZmljIGFuZCBhY3RpdmUgcHJvYmluZy4gIEluIGNhc2Ugb2YgbGl2ZSB0cmFmZmlj DQphIGNsYXNzaWZpZXIgdG8gc2VsZWN0IHN1YnNldCBvZiBsaXZlIHRyYWZmaWMgZm9yIGFkZGl0 aW9uLCB1cGRhdGUsDQpyZW1vdmFsIGFuZCByZXRyaWV2YWwgb2YgaW4tc2l0dSBPQU0gZGF0YS1y ZWNvcmRzLiBJbiBjYXNlIG9mIGFjdGl2ZQ0KcHJvYmluZyBwcm9jZWR1cmUgdG8gcmV0dXJuIHRo ZSBpbi1zaXR1IE9BTSBkYXRhIHJlY29yZHMgdG8gdGhlIHNvdXJjZSBvZg0KdGhlIHByb2JlLg0K KiAgU2NvcGUgb2YgaW4tc2l0dSBPQU0gb3BlcmF0aW9uLiBJbi1TaXR1IE9BTSBvcGVyYXRpb25z IGFyZSBkZWZpbmVkIGZvcg0KYSBzcGVjaWZpYyBvcGVyYXRpb25hbCBkb21haW4uIEluLXNpdHUg T0FNIGRhdGEtcmVjb3JkcyBhcmUgYWRkZWQgYW5kDQpyZW1vdmVkIGF0IGRvbWFpbiBib3VuZGFy aWVzIGFuZCB1cGRhdGVkIGJ5IG5vZGVzIHdpdGhpbiB0aGUgaW4tc2l0dSBPQU0NCmRvbWFpbi4g UHJvY2VkdXJlIHRvIGRlYWwgd2l0aCB2YXJpb3VzIGNoYWxsZW5nZXMgaW4gcGFja2V0IGZvcndh cmRpbmcNCmFuZCBlcnJvciBoYW5kbGluZyBzdWNoIGFzIEVDTVAgcHJvY2Vzc2luZywgcGF0aCBN VFUgYW5kIElDTVAgbWVzc2FnZQ0KaGFuZGxpbmcgd2hlbiBpbi1zaXR1IE9BTSBpcyBlbmFibGVk IGluIGFuIGluLXNpdHUgT0FNIGRvbWFpbi4NCiogIERhdGEtcmVjb3JkcyBmb3IgaW4tc2l0dSBP QU0gYXJlIHRvIGJlIGRlZmluZWQgaW4gYSB3YXkgdGhhdCBtYWtlcw0KdGhlbSBpbmRlcGVuZGVu dCBmcm9tIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgdXNlZC4gRGF0YS1yZWNvcmRzIGZvcg0KaW4t c2l0dSBPQU0gd2lsbCBuZWVkIHRvIGJlIGVtYmVkZGVkIGludG8gdHJhbnNwb3J0IHByb3RvY29s cyBzdWNoIGFzDQpJUHY0LCBJUHY2LCBWWExBTi1HUEUsIExJU1AsIE5TSCwgU1J2NiwgR2VuZXZl Lg0KKiBQcm9jZWR1cmVzIGFuZCBkYXRhLXJlY29yZHMgb3B0aW1pemVkIGZvciBzb2Z0d2FyZSBk YXRhcGxhbmUgYW5kDQpoYXJkd2FyZSBkYXRhcGxhbmUgaW1wbGVtZW50YXRpb25zIG9mIGluLXNp dHUgT0FNLg0KKiBJbi1zaXR1IE9BTSB0byBzdXBwb3J0IGxheWVyaW5nLiBJZiBzZXZlcmFsIHRy YW5zcG9ydCBwcm90b2NvbHMgKGUuZy4NCmluIGNhc2Ugb2YgdHVubmVsaW5nKSBhcmUgc3RhY2tl ZCBvbiB0b3Agb2YgZWFjaCBvdGhlciwgaW4tc2l0dSBPQU0NCmRhdGEtcmVjb3JkcyBjb3VsZCBi ZSBwcmVzZW50IGluIGV2ZXJ5IHRyYW5zcG9ydCBwcm90b2NvbCBsYXllci4NCiogTWFuYWdlbWVu dCBhbmQgY29udHJvbCBvZiByb2xlIG9mIG5vZGVzIGZvciBpbi1zaXR1IE9BTSBvcGVyYXRpb24s DQpkeW5hbWljIGNvbnRyb2wgb2YgaW4tc2l0dSBPQU0gZGF0YSBjb2xsZWN0ZWQgaW4gdGhlIGRh dGEgcmVjb3JkcywgZGF0YQ0KZXhwb3J0IG9wdGltaXphdGlvbi4NCg0KVGhlIElPQU0gd29ya2lu ZyBncm91cCBpbnRlbmRzIHRvIHdvcmsgb24gYW5kIHB1Ymxpc2g6DQoqIERlZmluaXRpb24gb2Yg dGhlIGRhdGEtdHlwZSBmb3JtYXRzIHVzZWQgaW4gaW4tc2l0dSBPQU0gYW5kIG5hbWVzcGFjZXMN CmZvciBpbi1zaXR1IE9BTS4NCiogRGVmaW5pdGlvbiBvZiBwcm9jZWR1cmVzIHRoYXQgaW4tc2l0 dSBPQU0gZW5hYmxlZCBub2RlcyB3aWxsIHBlcmZvcm0gb24NCmRhdGEgdHJhZmZpYyB0aGF0IGNh cnJpZXMgaW4tc2l0dSBPQU0gaW5mb3JtYXRpb24gKGUuZy4sIGludHJvZHVjaW5nLA0KcmVtb3Zp bmcsIHByb2Nlc3NpbmcsIG1vZGlmeWluZywgYW5kIGV4cG9ydGluZyB0aGUgdGVsZW1ldHJ5IGlu Zm9ybWF0aW9uDQpmcm9tIHRoZSBhc3NvY2lhdGVkIGRhdGEgcGFja2V0cykuDQoqIENvbmZpZ3Vy YXRpb24gYW5kIG9wZXJhdGlvbmFsIGRhdGEgbW9kZWxzIGZvciBjb250cm9sbGluZyBpbi1zaXR1 IE9BTQ0KZGF0YSBhbmQgb3BlcmF0aW9ucy4NCkluLXNpdHUgT0FNIGRhdGEgcmVjb3JkcyBjb3Vs ZCBiZSBlbWJlZGRlZCBpbnRvIGEgdmFyaWV0eSBvZiB0cmFuc3BvcnRzLg0KVGhlIHRyYW5zcG9y dHMgYXJlIGV4cGVjdGVkIHRvIGJlIGRlZmluZWQgaW4gdGhlIHJlc3BlY3RpdmUgd29ya2luZw0K Z3JvdXAocykgbGlrZSBOVk8zLCBTRkMsIDZtYW4sIE1QTFMgZXRjIGluIGNvbnN1bHRhdGlvbiB3 aXRoIHRoZSBJT0FNDQp3b3JraW5nIGdyb3VwIGRvY3VtZW50cy4gSU9BTSBXRyBleGNsdXNpdmVs eSBmb2N1c2VzIG9uIG1lY2hhbmlzbXMgd2hpY2gNCnBpZ2d5YmFjayBPQU0tcmVsYXRlZCBtZXRh ZGF0YSBvbnRvIGVuLXJvdXRlIHRyYWZmaWMgZm9yIE9BTSBwdXJwb3Nlcy4NCk90aGVyIG9uZ29p bmcgT0FNLXJlbGF0ZWQgZWZmb3J0cyBpbiB3b3JraW5nIGdyb3VwcyhzKSBzdWNoIGFzIE1QTFMg YW5kDQpJUFBNIHRoYXQgZG8gbm90IHBpZ2d5YmFjayBpbmZvcm1hdGlvbiBvbnRvIHRoZSBsaXZl IHVzZXIgZGF0YSB0cmFmZmljDQphcmUgb3V0IG9mIHNjb3BlIG9mIHRoZSBJT0FNIFdHLg0KDQpN aWxlc3RvbmVzDQoNCkFwcmlsIDIwMTggLSBzdWJtaXQgZGF0YSBmb3JtYXQgYW5kIGFzc29jaWF0 ZWQgcHJvY2VkdXJlcyBkb2N1bWVudCB0bw0KSUVTRy4NCk1hcmNoIDIwMTggLSBXR0xDIGZvciBk YXRhIGZvcm1hdCBhbmQgYXNzb2NpYXRlZCBwcm9jZWR1cmVzIGRvY3VtZW50Lg0KQXByaWwgMjAx NyAtIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gb2YgZGF0YSBmb3JtYXQgYW5kIGFzc29jaWF0ZWQN CnByb2NlZHVyZXMgZG9jdW1lbnQNCk1pbGVzdG9uZXM6DQoNCg0K --_000_E23424A5D78F4680B54234CD6BC59862ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0727172439CC3F47B84A2D3C3DD31DE3@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5TdGVw aGVuOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkhpITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPkkgdGhpbmsgdHJpY2t5LCBidXQgaW1wb3J0YW50LiZuYnNwOyBJ4oCZbSBjY+KAmWluZyB0 aGUgbGlzdCB0byBnZXQgdGhlIGFuc3dlcnMgdGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+VG8geW91ciBzZWNvbmQgcXVlc3Rpb24uJm5ic3A7IFllcywgdGhlcmUgY2xlYXJseSBpcyBh biBleHBlY3RhdGlvbiBvbiB0aGUgb3V0Y29tZSwgaWYgSVB2NiBpcyB1c2VkIGFzIGFuIGVuY2Fw c3VsYXRpbmcgcHJvdG9jb2wuJm5ic3A7IEJ1dCB0aGF0IGlzIG5vdCB0aGUgb25seSBhcHBsaWNh dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+QWx2YXJvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzkvMTcsIDM6MTUgUE0sICZxdW90O2llc2cgb24gYmVo YWxmIG9mIFN0ZXBoZW4gRmFycmVsbCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2ctYm91 bmNlc0BpZXRmLm9yZyI+aWVzZy1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxh IGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllIj5zdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaXlhLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgdHdvIHBvc3NpYmx5IHRy aWNreSBxdWVzdGlvbnMgYWJvdXQgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgSSdtIHN1cmUgdGhlcmUgYXJlIGdvb2QgdGhpbmdz IG9uZSBjYW4gZG8gd2l0aCBzdWNoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5tYXJraW5nLCBidXQgaXQgaXMgdmVyeSB1bmNsZWFyIHRvIG1lIGhv dyB0aGlzIHByb3Bvc2FsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5kb2Vzbid0IGFsc28gZmFsbCBhZm91bCBvZiBhbGwgdGhlIHByaXZhY3kgZG93 bnNpZGVzIG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj50aGUgU1BVRC9QTFVTIHByb3Bvc2FsLiBNeSB1bmRlcnN0YW5kaW5nIG9mIHRob3NlIHBy aXZhY3k8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmRvd25zaWRlcyB3YXMgdGhhdCBhbnkgZ2VuZXJpYy9leHRlbnNpYmxlIG1hcmtpbmcgc2NoZW1l PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4od2hl dGhlciBvZiBwYWNrZXRzIG9yIHRyYW5zcG9ydCBjb25uZWN0aW9ucy9mbG93cykgY291bGQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmVhc2lseSBi ZSBhYnVzZWQgaW4gbWFueSBwcml2YWN5IHVuZnJpZW5kbHkgd2F5cy4gTm90ZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhdCBJJ20gbm90IGNs YWltaW5nIHRoZXJlIGlzIElFVEYgY29uc2Vuc3VzIG9uIHRoYXQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCBJIGRvIGNsYWltIGl0IHdhcyBh IHNpZ25pZmljYW50IGlzc3VlIGZvciBTUFVEL1BMVVM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCB3b3VsZCBsaWtlIHRvIGtub3cgd2h5IChh bmQgaG9wZSkgaXQgaXMgbm90IGFuIGlzc3VlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5oZXJlLiBDYW4gc29tZW9uZSBoZWxwIG1lIHVuZGVyc3Rh bmQgd2hhdCdzIGRpZmZlcmVudCBoZXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5zbyB3ZSBhdm9pZCB0aGF0IHNhbWUga2luZCBvZiBtZWdhLWRl YmF0ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+MikgVGhlcmUgaXMgYW4gb25nb2luZyBhbmQgc2VlbWluZ2x5IHZlcnkgaGFyZCB0byByZXNv bHZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5k aXNjdXNzaW9uIFsxXSBvbiA8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRm Lm9yZzwvYT4gaW4gd2hpY2ggYSBkcmFmdCByZWxhdGVkIHRvPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGlzIHByb3Bvc2FsIGhhcyBiZWVuIHF1 b3RlZCBbMl0gYXMgZXZpZGVuY2Ugb24gb25lIHNpZGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9mIHRoZSBhcmd1bWVudC4gSSdtIG5vdCBjbGVh ciB0aGF0IHdlIHNob3VsZCBnbyBhaGVhZCB3aXRoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGlzIGNoYXJ0ZXIgYmVmb3JlIHdlIGhhdmUgZXN0 YWJsaXNoZWQgSUVURiBjb25zZW5zdXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPm9uZSB3YXkgb3IgYW5vdGhlciBhYm91dCB3aGF0IHdlIHRoaW5r IGFib3V0IFsxXSAoYnkgd2hpY2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgc3BlY2lmaWNhbGx5IG1lYW4gdGhlIGlzc3VlIG9mIGhlYWRlcnMg YmVpbmcgcHJvY2Vzc2VkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5hd2F5IGZyb20gdGhlIGVuZHBvaW50cykuIElmIEknbSByaWdodCB0aGF0IHRo ZXNlIGFyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+cmVsYXRlZCAoYW5kIGl0J3MgcG9zc2libGUgSSdtIGVudGlyZWx5IHdyb25nOy0pIHRoZW4g STxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Z3Vl c3MgZGVwZW5kaW5nIG9uIHRoZSBvdXRjb21lIG9mIFsxXSB0aGF0J2QgZWl0aGVyIG1lYW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEgc2hvcnQg ZGVsYXkgZm9yIHRoaXMsIG9yIGVsc2UgYSBuZWVkIGZvciBzb21lIG1ham9yPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jaGFuZ2UgYW5kIHRoYXQg cmlzayB3b3VsZCBzZWVtIHRvIG1lIHRvIGp1c3RpZnkgbm90PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mb3JnaW5nIGFoZWFkIHdpdGggdGhpcyBq dXN0IHlldC4gU28gdGhlIHF1ZXN0aW9uIGlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW0gSSByaWdodCB0aGF0IHRoaXMgcHJvcG9zYWwgYXNz dW1lcyBvbmUgb3V0Y29tZSBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+dGhlIGRpc2N1c3Npb24gYWJvdXQgaGVhZGVyIHByb2Nlc3NpbmcgaW4g WzFdPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5QUzogSSdtIGZpbmUgdG8gYXNrIHRoZXNlIHR3byBxdWVzdGlvbnMgaW4gYSBiYWxsb3Qg aWYgdGhhdCdzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5iZXR0ZXIuIEJ1dCBhdCB0aGUgbW9tZW50IHRoYXQnZCBsaWtlbHkgYmUgYSBCTE9DSyBi YWxsb3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnNvIEkgd2FudGVkIHRvIGNoZWNrIGZpcnN0IGlmIEknbSBvZmYgYmFzZSwgYXMgaGFwcGVucyBu b3c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFu ZCB0aGVuOi0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvaWV0Zi9jdXJyZW50L21zZzEwMDk2MC5odG1sIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvaWV0Zi9jdXJyZW50L21zZzEwMDk2MC5odG1sPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzJdIDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWV0Zi9jdXJyZW50L21zZzEwMTAx Mi5odG1sIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWV0Zi9jdXJy ZW50L21zZzEwMTAxMi5odG1sPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA4LzAyLzE3IDE4OjMyLCBJRVRGIFNlY3JldGFyaWF0 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QSBuZXcgSUVURiBXRyBpcyBiZWluZyBjb25zaWRlcmVkIGluIHRoZSBJRVRGLiBUaGUgZHJhZnQg Y2hhcnRlciBmb3IgdGhpczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V0cgaXMgcHJvdmlkZWQgYmVsb3cgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21t ZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UmV2aWV3IHRpbWUgaXMgb25lIHdlZWsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4tc2l0dSBPQU0gKGlvYW0pPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q3VycmVudCBzdGF0dXM6IFByb3Bvc2VkIFdHPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFpcnM6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgVEJEPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bc3NpZ25lZCBBcmVhIERp cmVjdG9yOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7IEFsdmFybyBSZXRhbmEgJmx0OzxhIGhyZWY9Im1haWx0bzphcmV0YW5h QGNpc2NvLmNvbSI+YXJldGFuYUBjaXNjby5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um91dGluZyBBcmVhIERpcmVjdG9yczo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyBBbGlhIEF0bGFzICZsdDs8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20i PmFrYXRsYXNAZ21haWwuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBBbHZhcm8gUmV0YW5hICZsdDs8YSBo cmVmPSJtYWlsdG86YXJldGFuYUBjaXNjby5jb20iPmFyZXRhbmFAY2lzY28uY29tPC9hPiZndDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyBEZWJvcmFoIEJydW5nYXJkICZsdDs8YSBocmVmPSJtYWlsdG86ZGIzNTQ2QGF0dC5j b20iPmRiMzU0NkBhdHQuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFpbGluZyBsaXN0OjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IEFkZHJl c3M6IDxhIGhyZWY9Im1haWx0bzppb2FtQGlldGYub3JnIj5pb2FtQGlldGYub3JnPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7IFRvIHN1YnNjcmliZTogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pb2FtIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW9h bTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyBBcmNoaXZlOiA8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvYnJvd3NlL2lvYW0vIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9icm93c2UvaW9hbS88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5DaGFydGVyOiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9jaGFydGVyLWlldGYtaW9hbS8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvY2hhcnRlci1pZXRmLWlvYW0vPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4tc2l0dSBPQU0gcHJvdmlkZXMgcmVhbC10aW1lIHRl bGVtZXRyeSBvZiBpbmRpdmlkdWFsIGRhdGEgcGFja2V0cyBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZsb3dzLiBJdCBpcyBiYXNlZCBvbiB0 ZWxlbWV0cnkgaW5mb3JtYXRpb24gd2hpY2ggaXMgZW1iZWRkZWQgd2l0aGluIGxpdmU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRhdGEgcGFja2V0 cy4gVGhlIElPQU0gV0cgaW50ZW5kcyB0byBkZWZpbmUgZGF0YSBmb3JtYXRzIGFuZCBhc3NvY2lh dGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5w cm9jZWR1cmVzIGZvciBpbi1zaXR1IE9BTSwgaW5jbHVkaW5nIG1lY2hhbmlzbXMgZm9yIGNhcHR1 cmluZyBwYXRoIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+cGF0aC10cmF2ZXJzYWwgcmVsYXRlZCBpbmZvcm1hdGlvbiBhcyB3ZWxsIGFzIHBy b2NlZHVyZXMgdG8gZW1wbG95LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Y29uZmlndXJlLCB0cmlnZ2VyLCBhbmQgZXhwb3J0IHRoZSBlbWJlZGRl ZCB0ZWxlbWV0cnkgaW5mb3JtYXRpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIElPQU0gV0cgd2lsbCBkZWZpbmUgdGhl IGZvbGxvd2luZyBpbi1zaXR1IE9BTSBjb21wb25lbnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIERhdGEtcmVjb3JkcyBmb3Ig aW4tc2l0dSBPQU0gdG8gY292ZXIgcGF0aC10cmFjaW5nIGFuZCBwYXRoPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj52ZXJpZmljYXRpb24gaW5mb3Jt YXRpb24gKG5vZGUtaWRzLCBpbmdyZXNzL2VncmVzcyBpbnRlcmZhY2VzKSw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRpbWVzdGFtcHMsIHRyYW5z aXQtZGVsYXksIHRyYW5zaXQgaml0dGVyLCBzZXF1ZW5jZSBudW1iZXJzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXBwbGljYXRpb24tZGVmaW5l ZCBtZXRhZGF0YS4gSW4tc2l0dSBPQU0gZGF0YS1yZWNvcmRzIGFyZSBkZWZpbmVkIHVzaW5nPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbiBpbi1z aXR1IE9BTSBuYW1lc3BhY2UuIEl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBjb250cm9sIHRoZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW5mb3Jt YXRpb24gdGhhdCBnZXRzIHJlY29yZGVkIGluIGRhdGEtcmVjb3Jkcy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogUHJvY2VkdXJlcyB0byBhZGQs IHVwZGF0ZSwgcmVtb3ZlLCByZXRyaWV2ZSBhbmQgZXhwb3J0IGRhdGEtcmVjb3JkcyBmb3I8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluLXNpdHUg T0FNIHRvIGxpdmUgdHJhZmZpYyBhbmQgYWN0aXZlIHByb2JpbmcuJm5ic3A7Jm5ic3A7SW4gY2Fz ZSBvZiBsaXZlIHRyYWZmaWM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmEgY2xhc3NpZmllciB0byBzZWxlY3Qgc3Vic2V0IG9mIGxpdmUgdHJhZmZp YyBmb3IgYWRkaXRpb24sIHVwZGF0ZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnJlbW92YWwgYW5kIHJldHJpZXZhbCBvZiBpbi1zaXR1IE9BTSBk YXRhLXJlY29yZHMuIEluIGNhc2Ugb2YgYWN0aXZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wcm9iaW5nIHByb2NlZHVyZSB0byByZXR1cm4gdGhl IGluLXNpdHUgT0FNIGRhdGEgcmVjb3JkcyB0byB0aGUgc291cmNlIG9mPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgcHJvYmUuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qJm5ic3A7Jm5ic3A7 U2NvcGUgb2YgaW4tc2l0dSBPQU0gb3BlcmF0aW9uLiBJbi1TaXR1IE9BTSBvcGVyYXRpb25zIGFy ZSBkZWZpbmVkIGZvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+YSBzcGVjaWZpYyBvcGVyYXRpb25hbCBkb21haW4uIEluLXNpdHUgT0FNIGRhdGEt cmVjb3JkcyBhcmUgYWRkZWQgYW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5yZW1vdmVkIGF0IGRvbWFpbiBib3VuZGFyaWVzIGFuZCB1cGRhdGVk IGJ5IG5vZGVzIHdpdGhpbiB0aGUgaW4tc2l0dSBPQU08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRvbWFpbi4gUHJvY2VkdXJlIHRvIGRlYWwgd2l0 aCB2YXJpb3VzIGNoYWxsZW5nZXMgaW4gcGFja2V0IGZvcndhcmRpbmc8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCBlcnJvciBoYW5kbGluZyBz dWNoIGFzIEVDTVAgcHJvY2Vzc2luZywgcGF0aCBNVFUgYW5kIElDTVAgbWVzc2FnZTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aGFuZGxpbmcgd2hl biBpbi1zaXR1IE9BTSBpcyBlbmFibGVkIGluIGFuIGluLXNpdHUgT0FNIGRvbWFpbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiombmJzcDsmbmJz cDtEYXRhLXJlY29yZHMgZm9yIGluLXNpdHUgT0FNIGFyZSB0byBiZSBkZWZpbmVkIGluIGEgd2F5 IHRoYXQgbWFrZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnRoZW0gaW5kZXBlbmRlbnQgZnJvbSB0aGUgdHJhbnNwb3J0IHByb3RvY29sIHVzZWQu IERhdGEtcmVjb3JkcyBmb3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmluLXNpdHUgT0FNIHdpbGwgbmVlZCB0byBiZSBlbWJlZGRlZCBpbnRvIHRy YW5zcG9ydCBwcm90b2NvbHMgc3VjaCBhczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SVB2NCwgSVB2NiwgVlhMQU4tR1BFLCBMSVNQLCBOU0gsIFNS djYsIEdlbmV2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiogUHJvY2VkdXJlcyBhbmQgZGF0YS1yZWNvcmRzIG9wdGltaXplZCBmb3Igc29mdHdh cmUgZGF0YXBsYW5lIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+aGFyZHdhcmUgZGF0YXBsYW5lIGltcGxlbWVudGF0aW9ucyBvZiBpbi1zaXR1 IE9BTS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiogSW4tc2l0dSBPQU0gdG8gc3VwcG9ydCBsYXllcmluZy4gSWYgc2V2ZXJhbCB0cmFuc3BvcnQg cHJvdG9jb2xzIChlLmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5pbiBjYXNlIG9mIHR1bm5lbGluZykgYXJlIHN0YWNrZWQgb24gdG9wIG9mIGVh Y2ggb3RoZXIsIGluLXNpdHUgT0FNPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5kYXRhLXJlY29yZHMgY291bGQgYmUgcHJlc2VudCBpbiBldmVyeSB0 cmFuc3BvcnQgcHJvdG9jb2wgbGF5ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4qIE1hbmFnZW1lbnQgYW5kIGNvbnRyb2wgb2Ygcm9sZSBvZiBu b2RlcyBmb3IgaW4tc2l0dSBPQU0gb3BlcmF0aW9uLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZHluYW1pYyBjb250cm9sIG9mIGluLXNpdHUgT0FN IGRhdGEgY29sbGVjdGVkIGluIHRoZSBkYXRhIHJlY29yZHMsIGRhdGE8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmV4cG9ydCBvcHRpbWl6YXRpb24u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBJT0FNIHdvcmtpbmcgZ3JvdXAgaW50ZW5kcyB0byB3b3JrIG9uIGFuZCBwdWJsaXNo OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBE ZWZpbml0aW9uIG9mIHRoZSBkYXRhLXR5cGUgZm9ybWF0cyB1c2VkIGluIGluLXNpdHUgT0FNIGFu ZCBuYW1lc3BhY2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5mb3IgaW4tc2l0dSBPQU0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4qIERlZmluaXRpb24gb2YgcHJvY2VkdXJlcyB0aGF0IGluLXNp dHUgT0FNIGVuYWJsZWQgbm9kZXMgd2lsbCBwZXJmb3JtIG9uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kYXRhIHRyYWZmaWMgdGhhdCBjYXJyaWVz IGluLXNpdHUgT0FNIGluZm9ybWF0aW9uIChlLmcuLCBpbnRyb2R1Y2luZyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlbW92aW5nLCBwcm9jZXNz aW5nLCBtb2RpZnlpbmcsIGFuZCBleHBvcnRpbmcgdGhlIHRlbGVtZXRyeSBpbmZvcm1hdGlvbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZnJvbSB0 aGUgYXNzb2NpYXRlZCBkYXRhIHBhY2tldHMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBDb25maWd1cmF0aW9uIGFuZCBvcGVyYXRpb25hbCBk YXRhIG1vZGVscyBmb3IgY29udHJvbGxpbmcgaW4tc2l0dSBPQU08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRhdGEgYW5kIG9wZXJhdGlvbnMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Jbi1zaXR1 IE9BTSBkYXRhIHJlY29yZHMgY291bGQgYmUgZW1iZWRkZWQgaW50byBhIHZhcmlldHkgb2YgdHJh bnNwb3J0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSB0cmFuc3BvcnRzIGFyZSBleHBlY3RlZCB0byBiZSBkZWZpbmVkIGluIHRoZSByZXNw ZWN0aXZlIHdvcmtpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmdyb3VwKHMpIGxpa2UgTlZPMywgU0ZDLCA2bWFuLCBNUExTIGV0YyBpbiBjb25z dWx0YXRpb24gd2l0aCB0aGUgSU9BTTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+d29ya2luZyBncm91cCBkb2N1bWVudHMuIElPQU0gV0cgZXhjbHVz aXZlbHkgZm9jdXNlcyBvbiBtZWNoYW5pc21zIHdoaWNoPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5waWdneWJhY2sgT0FNLXJlbGF0ZWQgbWV0YWRh dGEgb250byBlbi1yb3V0ZSB0cmFmZmljIGZvciBPQU0gcHVycG9zZXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PdGhlciBvbmdvaW5nIE9BTS1y ZWxhdGVkIGVmZm9ydHMgaW4gd29ya2luZyBncm91cHMocykgc3VjaCBhcyBNUExTIGFuZDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SVBQTSB0aGF0 IGRvIG5vdCBwaWdneWJhY2sgaW5mb3JtYXRpb24gb250byB0aGUgbGl2ZSB1c2VyIGRhdGEgdHJh ZmZpYzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ YXJlIG91dCBvZiBzY29wZSBvZiB0aGUgSU9BTSBXRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlsZXN0b25lczxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcHJpbCAy MDE4IC0gc3VibWl0IGRhdGEgZm9ybWF0IGFuZCBhc3NvY2lhdGVkIHByb2NlZHVyZXMgZG9jdW1l bnQgdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklFU0cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5NYXJjaCAyMDE4IC0gV0dMQyBmb3IgZGF0YSBmb3JtYXQgYW5kIGFzc29jaWF0ZWQgcHJvY2Vk dXJlcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFwcmlsIDIwMTcgLSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIG9mIGRhdGEgZm9y bWF0IGFuZCBhc3NvY2lhdGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5wcm9jZWR1cmVzIGRvY3VtZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWxlc3RvbmVzOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_E23424A5D78F4680B54234CD6BC59862ciscocom_-- From nobody Fri Feb 10 01:32:41 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67B8129572; Fri, 10 Feb 2017 01:32:37 -0800 (PST) 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, FREEMAIL_FROM=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 cJSF6DuRezjg; Fri, 10 Feb 2017 01:32:36 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 EB71F129542; Fri, 10 Feb 2017 01:32:35 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id r141so43067996wmg.1; Fri, 10 Feb 2017 01:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=OIMjRh/YgjrpmTY6PLYFCh7o2fPBSEyVDRHHaBKAtFw=; b=afJDdPnwwh1MEtEJjt5nbADadlZ+7rwwL4zPX+2jrkX/XO5Qz0HbNI/H4ZSPC+eLDl OqXIuxK9/JX5VaQPNIyVv5g4izusPhqKpfbE69CrgRVMuJrdhKHhoXYCD8j8Qb6gIfBD fVWDhqfDqroid74SnDiGfIy9ZncdQIrt2DTKEJQmj7tqL6UTscQr0XWN4eT5q3Jtkj9t O6jvZqVxJCi4JtBb/2cKmqb0JESsSKIPOtSjWVcWYqdgHccrHzEEAWxZe1aIjR1fQ17V ciMm+SjL5hnfWkjIvLzA7m8He7DUj4F4Gcssb+uoidvetF/5MQfdlqnBpWNf7oEZvqVm f+lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OIMjRh/YgjrpmTY6PLYFCh7o2fPBSEyVDRHHaBKAtFw=; b=nyesUV50PT0fKGiSpurOOO15db8oj9hKrqW3+rkegWIOMwPgooKdse6AU/3ldCl8gJ /L4zT95XLh6xSeuP+lofZH7I/pTRoacpOPZlB4SrQRS2014JwgBkAo6WOk7Wrv3lDcI9 8nTvg3o4q/vUfMxxPuYbkXwUD1kl0mewvBw3vo07liriZmzI2S2pORe9cRQejKVVT58C nVKbVSDGkZcH7KEzqvXB0D+w6Jrg8qXsIw8hncKvz86SK4IoZmm1XRVisFvNW+1pRB+1 QTglkaeDQLhHa5kD2lnFSlncom0ytJnn2wzw3JFebxQ2PCsBIVqoRJ0P/gXCGmQBCA6O Jd9A== X-Gm-Message-State: AMke39nEev7W+2VjspUwwuzBuMl1d/9Z6GozWoUSJDbQb4KeA4QxKWkyX6M5ayyQfa+iIQ== X-Received: by 10.28.113.9 with SMTP id m9mr27313910wmc.60.1486719154402; Fri, 10 Feb 2017 01:32:34 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id j80sm645976wmd.14.2017.02.10.01.32.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 01:32:33 -0800 (PST) To: "Carlos Pignataro (cpignata)" References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <4f16e222-97e4-6f87-e1a3-79115db8f355@gmail.com> From: Stewart Bryant Message-ID: <05a1d761-aed9-f62f-920b-93ed587a9fd4@gmail.com> Date: Fri, 10 Feb 2017 09:32:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "iesg@ietf.org" , "Alvaro Retana \(aretana\)" , The IAB , Spencer Dawkins at IETF , "ioam@ietf.org" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 09:32:38 -0000 On 09/02/2017 19:30, Carlos Pignataro (cpignata) wrote: > Hi, Stewart, > > Many thanks for the comments, please see inline. > >> On Feb 9, 2017, at 1:50 PM, Stewart Bryant wrote: >> >> >> >> On 09/02/2017 17:18, Carlos Pignataro (cpignata) wrote: >>> Passive means ‘solely by observation and without modification to the packet’ (https://tools.ietf.org/html/draft-ietf-ippm-active-passive-06#section-3.6). >> Carlos, that is not quit where we are going with passive. We use packet marking to batch the packets for loss measurement, and we are planning to trigger delay/jitter measurement through marking. >> > I’ll follow down this tangent for a bit. > > I understand and as you know I’m well aware of the (alternate) packet marking techniques and different methods. > > However, the *current* definition is quite unambiguous: > > 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). > “ > > Since both those datapoints are rooted in IPPM, I’d suggest working through the definitions on IPPM and how marking fits (since it is not only on observation points) > > Now, bringing this back to the relevance of the In-situ OAM (ioam) charter, my only point is that In-situ OAM is neither passive nor active. ... and the point I make is that packet marking (which I think we have established is the only viable way of making accurate loss measurements in connectionless networking) is also neither active of passive according to these definitions. > >> As you know marking is much easier in MPLS that IP. >> >> I think the key distinguisher is really that in-situ is about embedding OAM meta-data in user data traffic. > This is a good point. > > I agree. > > I believe this is already clear in the charter, all the way from the very first sentence: > > “ It is based on telemetry information which is embedded within live data packets.” > > Do you believe this is not clear in the charter? Do you have specific suggestions or concrete recommendations that can improve the charter text? I suppose you could say: It is based on telemetry information which is embedded within live data packets and is distinct from packet parking methods being developed elsewhere in the IETF. I have not thought it through, but I am wondering what distinguishes the packet types you list (IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, Geneve) from other packet types, the obvious one being MPLS. Not that I am at all keen on trying to get this into the simple fast forwarders we use for MPLS. In other words what is the generic class of packets you are targetting? Stewart > > Thanks! > >> - Stewart > > — > Carlos Pignataro, carlos@cisco.com > > “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis." > From nobody Fri Feb 10 04:32:25 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142B512962B for ; Fri, 10 Feb 2017 03:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 zEW0dKX7J6bU for ; Fri, 10 Feb 2017 03:58:09 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE148129631 for ; Fri, 10 Feb 2017 03:58:08 -0800 (PST) Received: (qmail 19559 invoked from network); 10 Feb 2017 12:58:07 +0100 Received: from p5dec2a07.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.42.7) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 10 Feb 2017 12:58:07 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <05a1d761-aed9-f62f-920b-93ed587a9fd4@gmail.com> Date: Fri, 10 Feb 2017 12:58:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <4f16e222-97e4-6f87-e1a3-79115db8f355@gmail.com> <05a1d761-aed9-f62f-920b-93ed587a9fd4@gmail.com> To: Stewart Bryant , "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.3259) Archived-At: X-Mailman-Approved-At: Fri, 10 Feb 2017 04:32:24 -0800 Cc: "Alvaro Retana \(aretana\)" , The IAB , "ioam@ietf.org" , "iesg@ietf.org" , Spencer Dawkins at IETF Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 11:58:12 -0000 Hi all, as a side notice: marking is define as hybrid measurement in the already = cited IPPM RFC 7799: "Augmentation or modification of the stream of interest, or employment of methods that modify the treatment of the stream =3D> Hybrid Type I=E2=80=9C Mirja > Am 10.02.2017 um 10:32 schrieb Stewart Bryant = : >=20 >=20 >=20 > On 09/02/2017 19:30, Carlos Pignataro (cpignata) wrote: >> Hi, Stewart, >>=20 >> Many thanks for the comments, please see inline. >>=20 >>> On Feb 9, 2017, at 1:50 PM, Stewart Bryant = wrote: >>>=20 >>>=20 >>>=20 >>> On 09/02/2017 17:18, Carlos Pignataro (cpignata) wrote: >>>> Passive means =E2=80=98solely by observation and without = modification to the packet=E2=80=99 = (https://tools.ietf.org/html/draft-ietf-ippm-active-passive-06#section-3.6= ). >>> Carlos, that is not quit where we are going with passive. We use = packet marking to batch the packets for loss measurement, and we are = planning to trigger delay/jitter measurement through marking. >>>=20 >> I=E2=80=99ll follow down this tangent for a bit. >>=20 >> I understand and as you know I=E2=80=99m well aware of the = (alternate) packet marking techniques and different methods. >>=20 >> However, the *current* definition is quite unambiguous: >>=20 >> https://tools.ietf.org/html/rfc7799#section-3.6 >> =E2=80=9C >> 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). >> =E2=80=9C >>=20 >> Since both those datapoints are rooted in IPPM, I=E2=80=99d suggest = working through the definitions on IPPM and how marking fits (since it = is not only on observation points) >>=20 >> Now, bringing this back to the relevance of the In-situ OAM (ioam) = charter, my only point is that In-situ OAM is neither passive nor = active. >=20 > ... and the point I make is that packet marking (which I think we have = established is the only viable way of making accurate loss measurements = in connectionless networking) is also neither active of passive = according to these definitions. >=20 >>=20 >>> As you know marking is much easier in MPLS that IP. >>>=20 >>> I think the key distinguisher is really that in-situ is about = embedding OAM meta-data in user data traffic. >> This is a good point. >>=20 >> I agree. >>=20 >> I believe this is already clear in the charter, all the way from the = very first sentence: >>=20 >> =E2=80=9C It is based on telemetry information which is embedded = within live data packets.=E2=80=9D >>=20 >> Do you believe this is not clear in the charter? Do you have specific = suggestions or concrete recommendations that can improve the charter = text? >=20 > I suppose you could say: It is based on telemetry information which is = embedded within live data packets and is distinct from packet parking = methods being developed elsewhere in the IETF. >=20 > I have not thought it through, but I am wondering what distinguishes = the packet types you list (IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, = Geneve) from other packet types, the obvious one being MPLS. Not that I = am at all keen on trying to get this into the simple fast forwarders we = use for MPLS. In other words what is the generic class of packets you = are targetting? >=20 > Stewart >=20 >>=20 >> Thanks! >>=20 >>> - Stewart >>=20 >> =E2=80=94 >> Carlos Pignataro, carlos@cisco.com >>=20 >> =E2=80=9CSometimes I use big words that I do not fully understand, to = make myself sound more photosynthesis." >>=20 >=20 From nobody Fri Feb 10 04:32:29 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7345F129636 for ; Fri, 10 Feb 2017 04:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 vuoQ7gBw7YnK for ; Fri, 10 Feb 2017 04:16:56 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5653612959A for ; Fri, 10 Feb 2017 04:16:56 -0800 (PST) Received: (qmail 19901 invoked from network); 10 Feb 2017 13:10:13 +0100 Received: from p5dec2a07.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.42.7) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 10 Feb 2017 13:10:13 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> Date: Fri, 10 Feb 2017 13:10:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> To: "Carlos Pignataro (cpignata)" , "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3259) Archived-At: X-Mailman-Approved-At: Fri, 10 Feb 2017 04:32:24 -0800 Cc: "iesg@ietf.org" , The IAB , Spencer Dawkins at IETF , "ioam@ietf.org" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 12:16:57 -0000 Hi all, also one more comment on this point: > Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata) = : >=20 >>> Is there any connection with IPPM? >=20 > Yes, there is, as already mentioned above. The charter currently says: "Other ongoing OAM-related efforts in working groups(s) such as MPLS and IPPM that do not piggyback information onto the live user data traffic are out of scope of the IOAM WG.=E2=80=9C which indictates that cooperation with IPPM is not planned. To me in general the relation between this work and other ongoing work = in the IETF is not very clear and IPPM has several documents and = milestones that are in scope for this work: - Submit a draft on the IPv6 Performance and Diagnostic Metrics (PDM) = Destination Option as Proposed Standard: draft-ietf-ippm-6man-pdm-option = (this draft is mainly done and silenter the publication process soon to = my understanding) - Submit an Experimental draft on coloring-based hybrid measurement = methodologies for loss and delay to the IESG: = draft-ietf-ippm-alt-mark-03 I don=E2=80=99t think that the assessment in the charter that IPPM's = scope does not include piggybacked information is correct. Looking at = draft-brockners-inband-oam-transport-02, I think that any work on IPV6 = and IPv6 in this scope should be done in IPPM because that=E2=80=99s = were this work is already on-going and where the measurement expertise = is. Mirja From nobody Fri Feb 10 05:39:00 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5061B129976; Fri, 10 Feb 2017 05:38:59 -0800 (PST) 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 8SIW-6WTtZyw; Fri, 10 Feb 2017 05:38:57 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811EE129975; Fri, 10 Feb 2017 05:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4882; q=dns/txt; s=iport; t=1486733937; x=1487943537; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=L9JvbFxGwGAfkGmcVDLTLGpBOKLUi6/0R7ICo8/Lyf8=; b=FegzUaNefPC3Jwn/xXL4I9xN0uiBkMcME0ZW7IkSzW1KmRlQkXm7eQ/D bWzoIiOBniZD7Hvz74rk55JybIyOHBsMu+BVZEQVDa9d9pRiKgNXyUMXU DOLlH/3Xz3m/B6GiELlUgsj8+16oC5DQTYuwHZhpaDJeMaPHtR+3lEMqS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CIAQAkwZ1Y/4cNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygqYYEJB4NSigiSDIgMjSqCDR8LhXgCGoJcPxgBAgEBAQEBAQF?= =?us-ascii?q?iKIRpAQEBAwEBASERNwMEBwUHBAIBCBEEAQEDAiMDAgICHwYLFAEICAIEAQ0FC?= =?us-ascii?q?IlYAw0IDq9VgiWHOA2EDgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFQYRvglG?= =?us-ascii?q?BVIM1gl8Fmzg6AY16hBCCBIhnhiOKNYhfAR84fk8VPIREHYFhdYkSgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,141,1484006400"; d="scan'208";a="382476382" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2017 13:38:56 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1ADcuSZ030162 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 13:38:56 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Feb 2017 07:38:56 -0600 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, 10 Feb 2017 07:38:55 -0600 From: "Frank Brockners (fbrockne)" To: "Mirja Kuehlewind (IETF)" , "Carlos Pignataro (cpignata)" , "Alvaro Retana (aretana)" Thread-Topic: [Ioam] Internal WG Review: In-situ OAM (ioam) Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFf5E4AgAECTQCAAFm/gIABTQoA//+ulhA= Date: Fri, 10 Feb 2017 13:38:55 +0000 Message-ID: <0bdcfd0be2c84ffa81b1658af60f084d@XCH-RCD-008.cisco.com> References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> In-Reply-To: <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> 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.190.236] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: The IAB , "ioam@ietf.org" , "iesg@ietf.org" , Spencer Dawkins at IETF Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 13:38:59 -0000 SGkgTWlyamEsDQoNCnlvdSByYWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludC4gVGhlIElQUE0gY2hh cnRlciBzdGF0ZXMgICIgU3BlY2lmeWluZyBuZXR3b3JrIG9yIGxvd2VyIGxheWVyIE9BTSBtZWNo YW5pc21zIGlzIG91dCBvZiBzY29wZSBvZiB0aGUgSVBQTSBjaGFydGVyLiIsIHdoZXJlYXMgdGhl IFdHIGhhcyAiIFN1Ym1pdCBhIGRyYWZ0IG9uIHRoZSBJUHY2IFBlcmZvcm1hbmNlIGFuZCBEaWFn bm9zdGljIE1ldHJpY3MgKFBETSkgRGVzdGluYXRpb24gT3B0aW9uIGFzIFByb3Bvc2VkIFN0YW5k YXJkIA0KZHJhZnQtaWV0Zi1pcHBtLTZtYW4tcGRtLW9wdGlvbiIgYXMgYSBtaWxlc3RvbmUuIEkn ZCBhc3N1bWUgdGhhdCB3ZSdkIGxpa2VseSBxdWFsaWZ5IElQdjYgYXMgYSB0cmFuc3BvcnQgcHJv dG9jb2wuLi4gDQoNClNvIGZhciBJIHVuZGVyc3Rvb2QgdGhlIG1haW4gZm9jdXMgb2YgdGhlIG5l dyBJT0FNIFdHIHRvIGJlIG5ldHdvcmstbGF5ZXIgZm9jdXNlZCwgaS5lLiBwaWdneWJhY2sgT0FN LW1ldGEtZGF0YSBvbnRvIG5ldHdvcmstbGF5ZXIgcHJvdG9jb2xzIC0gYnV0IHRoYXQgZG9lcyBu b3QgbmVjZXNzYXJpbHkgbmVlZCB0byBiZSBhbHdheXMgdGhlIGNhc2UgYXMgeW91IGltcGxpY2l0 bHkgaGlnaGxpZ2h0IGJ5IGRyYXdpbmcgdGhlIGxpbmsgdG8gSVBQTS4gT25lIGNvdWxkIGFsc28g ZG8gc28gdXNpbmcgZS5nLiBUQ1Agb3B0aW9ucy4gSSBkaWQgbm90IHJlYWQgdGhlIHN0YXRlbWVu dCBvbiBJUFBNIGluIHRoZSBkcmFmdCBjaGFydGVyIGFzICJub3QgY29vcGVyYXRpbmcgd2l0aCBJ UFBNIiAtIEkgcmVhZCBpdCBpbiBhIHdheSB0aGF0IG1ldGhvZHMgdGhhdCBkbyBub3QgcGlnZ3li YWNrIGluZm9ybWF0aW9uIG9uIGxpdmUgdHJhZmZpYyBhcmUgbm90IGNvbnNpZGVyZWQgaW4gSU9B TS4gVGhhdCBzYWlkLCBlc3BlY2lhbGx5IHdoZW4gaXQgY29tZXMgdG8gZXhwb3J0IGFuZCBpbnRl cnByZXRhdGlvbiBvZiBpbi1zaXR1IE9BTSBkYXRhLCB0aGVyZSBtaWdodCBpbmRlZWQgYmUgY29t bW9uIGdyb3VuZCBiZXR3ZWVuIElPQU0gYW5kIElQUE0uDQoNCkhvdyBhYm91dCB3ZSBhZGQgYW5v dGhlciBzZW50ZW5jZSB0byB0aGUgY2hhcnRlciB0aGF0IHVuZGVybGluZXMgdGhlIGZhY3QgdGhh dCBJT0FNIHdvdWxkIGFjdGl2ZWx5IHNlZWsgY29vcGVyYXRpb24gd2l0aCBvdGhlciByZWxhdGVk IGVmZm9ydHM/IFdlIGNvdWxkIGFkZCBzb21ldGhpbmcgbGlrZTogDQoNCiJUaGUgSU9BTSBXRyBz ZWVrcyBjb29wZXJhdGlvbiB3aXRoIG90aGVyIGFwcHJvcHJpYXRlIHN0YW5kYXJkcyBib2RpZXMg YW5kIGZvcnVtcyB0byBwcm9tb3RlIGNvbnNpc3RlbnQgYXBwcm9hY2hlcywgYXMgd2VsbCBhcyBk ZWZpbml0aW9uIGFuZCBpbnRlcnByZXRhdGlvbiBvZiBpbi1zaXR1IE9BTSBkYXRhLiINCg0KVGhp cyB3b3VsZCBuYXR1cmFsbHkgY2FwdHVyZSBJRVRGIFdHcyBsaWtlIElQUE0gLSBidXQgYWxzbyBl ZmZvcnRzIGxpa2UgSU5UIGluIFA0LCBoZW5jZSB3ZSdkIGV2ZW4gY2FzdCB0aGUgbmV0IGEgbGl0 dGxlIHdpZGVyLg0KDQpUaG91Z2h0cz8NCg0KVGhhbmtzLCBGcmFuaw0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogSW9hbSBbbWFpbHRvOmlvYW0tYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpDQpTZW50OiBGcmVpdGFnLCAxMC4g RmVicnVhciAyMDE3IDEzOjEwDQpUbzogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxjcGln bmF0YUBjaXNjby5jb20+OyBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSA8YXJldGFuYUBjaXNjby5j b20+DQpDYzogaWVzZ0BpZXRmLm9yZzsgVGhlIElBQiA8aWFiQGlhYi5vcmc+OyBTcGVuY2VyIERh d2tpbnMgYXQgSUVURiA8c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+OyBpb2FtQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0lvYW1dIEludGVybmFsIFdHIFJldmlldzogSW4tc2l0dSBPQU0g KGlvYW0pDQoNCkhpIGFsbCwNCg0KYWxzbyBvbmUgbW9yZSBjb21tZW50IG9uIHRoaXMgcG9pbnQ6 DQoNCj4gQW0gMDkuMDIuMjAxNyB1bSAxODoxOCBzY2hyaWViIENhcmxvcyBQaWduYXRhcm8gKGNw aWduYXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPjoNCj4gDQo+Pj4gSXMgdGhlcmUgYW55IGNvbm5l Y3Rpb24gd2l0aCBJUFBNPw0KPiANCj4gWWVzLCB0aGVyZSBpcywgYXMgYWxyZWFkeSBtZW50aW9u ZWQgYWJvdmUuDQoNCg0KVGhlIGNoYXJ0ZXIgY3VycmVudGx5IHNheXM6DQoNCiJPdGhlciBvbmdv aW5nIE9BTS1yZWxhdGVkIGVmZm9ydHMgaW4gd29ya2luZyBncm91cHMocykgc3VjaCBhcyBNUExT IGFuZCBJUFBNIHRoYXQgZG8gbm90IHBpZ2d5YmFjayBpbmZvcm1hdGlvbiBvbnRvIHRoZSBsaXZl IHVzZXIgZGF0YSB0cmFmZmljIGFyZSBvdXQgb2Ygc2NvcGUgb2YgdGhlIElPQU0gV0cu4oCcDQoN CndoaWNoIGluZGljdGF0ZXMgdGhhdCBjb29wZXJhdGlvbiB3aXRoIElQUE0gaXMgbm90IHBsYW5u ZWQuDQoNClRvIG1lIGluIGdlbmVyYWwgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhpcyB3b3JrIGFu ZCBvdGhlciBvbmdvaW5nIHdvcmsgaW4gdGhlIElFVEYgaXMgbm90IHZlcnkgY2xlYXIgYW5kIElQ UE0gaGFzIHNldmVyYWwgZG9jdW1lbnRzIGFuZCBtaWxlc3RvbmVzIHRoYXQgYXJlIGluIHNjb3Bl IGZvciB0aGlzIHdvcms6DQoNCi0gU3VibWl0IGEgZHJhZnQgb24gdGhlIElQdjYgUGVyZm9ybWFu Y2UgYW5kIERpYWdub3N0aWMgTWV0cmljcyAoUERNKSBEZXN0aW5hdGlvbiBPcHRpb24gYXMgUHJv cG9zZWQgU3RhbmRhcmQ6IGRyYWZ0LWlldGYtaXBwbS02bWFuLXBkbS1vcHRpb24gKHRoaXMgZHJh ZnQgaXMgbWFpbmx5IGRvbmUgYW5kIHNpbGVudGVyIHRoZSBwdWJsaWNhdGlvbiBwcm9jZXNzIHNv b24gdG8gbXkgdW5kZXJzdGFuZGluZykNCg0KLSBTdWJtaXQgYW4gRXhwZXJpbWVudGFsIGRyYWZ0 IG9uIGNvbG9yaW5nLWJhc2VkIGh5YnJpZCBtZWFzdXJlbWVudCBtZXRob2RvbG9naWVzIGZvciBs b3NzIGFuZCBkZWxheSB0byB0aGUgSUVTRzogZHJhZnQtaWV0Zi1pcHBtLWFsdC1tYXJrLTAzDQoN CkkgZG9u4oCZdCB0aGluayB0aGF0IHRoZSBhc3Nlc3NtZW50IGluIHRoZSBjaGFydGVyIHRoYXQg SVBQTSdzIHNjb3BlIGRvZXMgbm90IGluY2x1ZGUgcGlnZ3liYWNrZWQgaW5mb3JtYXRpb24gaXMg Y29ycmVjdC4gTG9va2luZyBhdCBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS10cmFuc3BvcnQt MDIsIEkgdGhpbmsgdGhhdCBhbnkgd29yayBvbiBJUFY2IGFuZCBJUHY2IGluIHRoaXMgc2NvcGUg c2hvdWxkIGJlIGRvbmUgaW4gSVBQTSBiZWNhdXNlIHRoYXTigJlzIHdlcmUgdGhpcyB3b3JrIGlz IGFscmVhZHkgb24tZ29pbmcgYW5kIHdoZXJlIHRoZSBtZWFzdXJlbWVudCBleHBlcnRpc2UgaXMu DQoNCk1pcmphDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpJb2FtIG1haWxpbmcgbGlzdA0KSW9hbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pb2FtDQo= From nobody Fri Feb 10 06:21:08 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228A5129979; Fri, 10 Feb 2017 06:21:04 -0800 (PST) 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 At_lW2jYrxPD; Fri, 10 Feb 2017 06:21:02 -0800 (PST) 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 686EF128B38; Fri, 10 Feb 2017 06:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5834; q=dns/txt; s=iport; t=1486736462; x=1487946062; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N9QhKGSP9j3XVpGieaygvi5k78iKWDB0PcFXUL2Pm4s=; b=IGwJM05v0hRkMXfkhtT6sD+IIq1y96JJIqwNHvzDP57r1B2+l4mUT/hO bit6f2gBwtsowxD1XiP0AKXCMmuOLDUVpftLS3GFqZ7CgnygFY3HlbKSi GUVPKbcbLk+xuJn1XR47feCmfh/Vb3ZRlZzxvyqPy1kQUm9V0xg9l/aAz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwAQDuy51Y/5ldJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1JhgQkHg1KKCJFtH4gMjSqCDSyFdgIaglw/GAECAQEBAQEBAWI?= =?us-ascii?q?ohGkBAQEDASMRRQULAgEGAhgCAiYCAgIfERUQAgQOBYlgAw0IDpIKnU6CJYc3D?= =?us-ascii?q?YQOAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VBggUIgmKCUYFfO4JvLoIxBZV?= =?us-ascii?q?UhWQ6AYZuhwyEGYF7hReJc4o1iF8BHzh+TxUYJBEBhDIdgWF1AYdhgTCBDAEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.35,141,1484006400"; d="scan'208";a="383119834" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2017 14:21:01 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1AEL13N032727 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 14:21:01 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Feb 2017 09:21:00 -0500 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; Fri, 10 Feb 2017 09:21:00 -0500 From: "Carlos Pignataro (cpignata)" To: Stewart Bryant Thread-Topic: [Ioam] Internal WG Review: In-situ OAM (ioam) Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFf5E4AgAECTQCAAFm/gIAAGdcAgAALP4CAAOsigIAAUJoA Date: Fri, 10 Feb 2017 14:21:00 +0000 Message-ID: <4E3165FB-0EFE-4784-8E3F-91538DED6110@cisco.com> References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <4f16e222-97e4-6f87-e1a3-79115db8f355@gmail.com> <05a1d761-aed9-f62f-920b-93ed587a9fd4@gmail.com> In-Reply-To: <05a1d761-aed9-f62f-920b-93ed587a9fd4@gmail.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.150.48.110] Content-Type: text/plain; charset="utf-8" Content-ID: <4C28975A49F83C41B054FE827D3DE46A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "iesg@ietf.org" , "Alvaro Retana \(aretana\)" , The IAB , Spencer Dawkins at IETF , "ioam@ietf.org" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:21:04 -0000 SGksIFN0ZXdhcnQsDQoNCg0KPiBPbiBGZWIgMTAsIDIwMTcsIGF0IDQ6MzIgQU0sIFN0ZXdhcnQg QnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gDQo+IA0KPiBP biAwOS8wMi8yMDE3IDE5OjMwLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6DQo+ PiBIaSwgU3Rld2FydCwNCj4+IA0KPj4gTWFueSB0aGFua3MgZm9yIHRoZSBjb21tZW50cywgcGxl YXNlIHNlZSBpbmxpbmUuDQo+PiANCj4+PiBPbiBGZWIgOSwgMjAxNywgYXQgMTo1MCBQTSwgU3Rl d2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4g DQo+Pj4gDQo+Pj4gT24gMDkvMDIvMjAxNyAxNzoxOCwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25h dGEpIHdyb3RlOg0KPj4+PiBQYXNzaXZlIG1lYW5zIOKAmHNvbGVseSBieSBvYnNlcnZhdGlvbiBh bmQgd2l0aG91dCBtb2RpZmljYXRpb24gdG8gdGhlIHBhY2tldOKAmSAoaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1hY3RpdmUtcGFzc2l2ZS0wNiNzZWN0aW9uLTMu NikuDQo+Pj4gQ2FybG9zLCB0aGF0IGlzIG5vdCBxdWl0IHdoZXJlIHdlIGFyZSBnb2luZyB3aXRo IHBhc3NpdmUuIFdlIHVzZSBwYWNrZXQgbWFya2luZyB0byBiYXRjaCB0aGUgcGFja2V0cyBmb3Ig bG9zcyBtZWFzdXJlbWVudCwgYW5kIHdlIGFyZSBwbGFubmluZyB0byB0cmlnZ2VyIGRlbGF5L2pp dHRlciBtZWFzdXJlbWVudCB0aHJvdWdoIG1hcmtpbmcuDQo+Pj4gDQo+PiBJ4oCZbGwgZm9sbG93 IGRvd24gdGhpcyB0YW5nZW50IGZvciBhIGJpdC4NCj4+IA0KPj4gSSB1bmRlcnN0YW5kIGFuZCBh cyB5b3Uga25vdyBJ4oCZbSB3ZWxsIGF3YXJlIG9mIHRoZSAoYWx0ZXJuYXRlKSBwYWNrZXQgbWFy a2luZyB0ZWNobmlxdWVzIGFuZCBkaWZmZXJlbnQgbWV0aG9kcy4NCj4+IA0KPj4gSG93ZXZlciwg dGhlICpjdXJyZW50KiBkZWZpbml0aW9uIGlzIHF1aXRlIHVuYW1iaWd1b3VzOg0KPj4gDQo+PiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzc5OSNzZWN0aW9uLTMuNg0KPj4g4oCcDQo+ PiAzLjYuICBQYXNzaXZlIE1ldGhvZHMNCj4+IA0KPj4gICAgUGFzc2l2ZSBNZXRob2RzIG9mIE1l YXN1cmVtZW50IGFyZToNCj4+IA0KPj4gICAgbyAgYmFzZWQgc29sZWx5IG9uIG9ic2VydmF0aW9u cyBvZiBhbiB1bmRpc3R1cmJlZCBhbmQgdW5tb2RpZmllZA0KPj4gICAgICAgcGFja2V0IHN0cmVh bSBvZiBpbnRlcmVzdCAoaW4gb3RoZXIgd29yZHMsIHRoZSBtZXRob2Qgb2YNCj4+ICAgICAgIG1l YXN1cmVtZW50IE1VU1QgTk9UIGFkZCwgY2hhbmdlLCBvciByZW1vdmUgcGFja2V0cyBvciBmaWVs ZHMgb3INCj4+ICAgICAgIGNoYW5nZSBmaWVsZCB2YWx1ZXMgYW55d2hlcmUgYWxvbmcgdGhlIHBh dGgpLg0KPj4g4oCcDQo+PiANCj4+IFNpbmNlIGJvdGggdGhvc2UgZGF0YXBvaW50cyBhcmUgcm9v dGVkIGluIElQUE0sIEnigJlkIHN1Z2dlc3Qgd29ya2luZyB0aHJvdWdoIHRoZSBkZWZpbml0aW9u cyBvbiBJUFBNIGFuZCBob3cgbWFya2luZyBmaXRzIChzaW5jZSBpdCBpcyBub3Qgb25seSBvbiBv YnNlcnZhdGlvbiBwb2ludHMpDQo+PiANCj4+IE5vdywgYnJpbmdpbmcgdGhpcyBiYWNrIHRvIHRo ZSByZWxldmFuY2Ugb2YgdGhlIEluLXNpdHUgT0FNIChpb2FtKSBjaGFydGVyLCBteSBvbmx5IHBv aW50IGlzIHRoYXQgSW4tc2l0dSBPQU0gaXMgbmVpdGhlciBwYXNzaXZlIG5vciBhY3RpdmUuDQo+ IA0KPiAuLi4gYW5kIHRoZSBwb2ludCBJIG1ha2UgaXMgdGhhdCBwYWNrZXQgbWFya2luZyAod2hp Y2ggSSB0aGluayB3ZSBoYXZlIGVzdGFibGlzaGVkIGlzIHRoZSBvbmx5IHZpYWJsZSB3YXkgb2Yg bWFraW5nIGFjY3VyYXRlIGxvc3MgbWVhc3VyZW1lbnRzIGluIGNvbm5lY3Rpb25sZXNzIG5ldHdv cmtpbmcpIGlzIGFsc28gbmVpdGhlciBhY3RpdmUgb2YgcGFzc2l2ZSBhY2NvcmRpbmcgdG8gdGhl c2UgZGVmaW5pdGlvbnMuDQoNClRoYXQgaXMgY29ycmVjdCwgaXQgaXMgSHlicmlkIFR5cGUgSS4g U29ycnkgaWYgSSBtaXN1bmRlcnN0b29kIHdoZW4geW91IHNhaWQg4oCcIENhcmxvcywgdGhhdCBp cyBub3QgcXVpdCB3aGVyZSB3ZSBhcmUgZ29pbmcgd2l0aCBwYXNzaXZlLiBXZSB1c2UgcGFja2V0 IG1hcmtpbmcgW+KApl3igJ0uIA0KDQpCdXQgaW4gYW55IGNhc2UsIEkgZG8gbm90IGJlbGlldmUg dGhlIGRyYWZ0IGNoYXJ0ZXIgY2xhaW1zIHRvIGRvIG1hcmtpbmcgKG1vcmUgb24gdGhpcyBiZWxv dyB0aG91Z2gpLg0KDQpJIHdvbmRlciwgYXMgYW4gYXNpZGUsIGlmIHRoZXJl4oCZcyBhbnkgdGFr ZS1hd2F5IGZvciBkcmFmdC1pZXRmLWlwcG0tYWx0LW1hcmstMDPigJlzIHRpdGxlIOKAnEFsdGVy bmF0ZSBNYXJraW5nIG1ldGhvZCBmb3IgcGFzc2l2ZSBwZXJmb3JtYW5jZSBtb25pdG9yaW5n4oCd Lg0KDQo+IA0KPj4gDQo+Pj4gQXMgeW91IGtub3cgbWFya2luZyBpcyBtdWNoIGVhc2llciBpbiBN UExTIHRoYXQgSVAuDQo+Pj4gDQo+Pj4gSSB0aGluayB0aGUga2V5IGRpc3Rpbmd1aXNoZXIgaXMg cmVhbGx5IHRoYXQgaW4tc2l0dSBpcyBhYm91dCBlbWJlZGRpbmcgT0FNIG1ldGEtZGF0YSBpbiB1 c2VyIGRhdGEgdHJhZmZpYy4NCj4+IFRoaXMgaXMgYSBnb29kIHBvaW50Lg0KPj4gDQo+PiBJIGFn cmVlLg0KPj4gDQo+PiBJIGJlbGlldmUgdGhpcyBpcyBhbHJlYWR5IGNsZWFyIGluIHRoZSBjaGFy dGVyLCBhbGwgdGhlIHdheSBmcm9tIHRoZSB2ZXJ5IGZpcnN0IHNlbnRlbmNlOg0KPj4gDQo+PiDi gJwgSXQgaXMgYmFzZWQgb24gdGVsZW1ldHJ5IGluZm9ybWF0aW9uIHdoaWNoIGlzIGVtYmVkZGVk IHdpdGhpbiBsaXZlIGRhdGEgcGFja2V0cy7igJ0NCj4+IA0KPj4gRG8geW91IGJlbGlldmUgdGhp cyBpcyBub3QgY2xlYXIgaW4gdGhlIGNoYXJ0ZXI/IERvIHlvdSBoYXZlIHNwZWNpZmljIHN1Z2dl c3Rpb25zIG9yIGNvbmNyZXRlIHJlY29tbWVuZGF0aW9ucyB0aGF0IGNhbiBpbXByb3ZlIHRoZSBj aGFydGVyIHRleHQ/DQo+IA0KPiBJIHN1cHBvc2UgeW91IGNvdWxkIHNheTogSXQgaXMgYmFzZWQg b24gdGVsZW1ldHJ5IGluZm9ybWF0aW9uIHdoaWNoIGlzIGVtYmVkZGVkIHdpdGhpbiBsaXZlIGRh dGEgcGFja2V0cyBhbmQgaXMgZGlzdGluY3QgZnJvbSBwYWNrZXQgcGFya2luZyBtZXRob2RzIGJl aW5nIGRldmVsb3BlZCBlbHNld2hlcmUgaW4gdGhlIElFVEYuDQo+IA0KDQpUaGF04oCZcyBvbmUg cG90ZW50aWFsIGFwcHJvYWNoLiBUbyBtZSwgdGhvdWdoLCDigJxlbWJlZGRlZCB3aXRoaW4gbGl2 ZSBkYXRhIHBhY2tldHPigJ0gaXMgZGlmZmVyZW50IGZyb20g4oCcbWFya2luZyBwYWNrZXRz4oCd OyB0aGF0IHNhaWQsIEkgZG8gbm90IHNlZSBob3cgaXQgY2FuIGh1cnQuDQoNClRoZXJlIGlzIG9u ZSBhZGRpdGlvbmFsIHdyaW5rbGUgdGhvdWdoOiBJT0FNIGlzIG5vdCBsaW1pdGVkIHRvIFBlcmZv cm1hbmNlIE1hbmFnZW1lbnQgKFBNKSwgYnV0IG1vcmUgZ2VuZXJhbGx5IGluY2x1ZGVzIHRoaW5n cyBsaWtlIHBhdGggdHJhY2luZy4gU28gcGVyaGFwcyBhZGRpbmcgdGhlIHRleHQgYWJvdmUgbWln aHQgY2F1c2UgY29uZnVzaW9ucy4NCg0KPiBJIGhhdmUgbm90IHRob3VnaHQgaXQgdGhyb3VnaCwg YnV0IEkgYW0gd29uZGVyaW5nIHdoYXQgZGlzdGluZ3Vpc2hlcyB0aGUgcGFja2V0IHR5cGVzIHlv dSBsaXN0IChJUHY0LCBJUHY2LCBWWExBTi1HUEUsIExJU1AsIE5TSCwgU1J2NiwgR2VuZXZlKSBm cm9tIG90aGVyIHBhY2tldCB0eXBlcywgdGhlIG9idmlvdXMgb25lIGJlaW5nIE1QTFMuIE5vdCB0 aGF0IEkgYW0gYXQgYWxsIGtlZW4gb24gdHJ5aW5nIHRvIGdldCB0aGlzIGludG8gdGhlIHNpbXBs ZSBmYXN0IGZvcndhcmRlcnMgd2UgdXNlIGZvciBNUExTLiBJbiBvdGhlciB3b3JkcyB3aGF0IGlz IHRoZSBnZW5lcmljIGNsYXNzIG9mIHBhY2tldHMgeW91IGFyZSB0YXJnZXR0aW5nPw0KPiANCg0K RW5jYXBzdWxhdGlvbnM/DQoNClRoYW5rcyENCg0K4oCUIENhcmxvcy4NCg0KPiBTdGV3YXJ0DQo+ IA0KPj4gDQo+PiBUaGFua3MhDQo+PiANCj4+PiAtIFN0ZXdhcnQNCj4+IA0KPj4g4oCUDQo+PiBD YXJsb3MgUGlnbmF0YXJvLCBjYXJsb3NAY2lzY28uY29tDQo+PiANCj4+IOKAnFNvbWV0aW1lcyBJ IHVzZSBiaWcgd29yZHMgdGhhdCBJIGRvIG5vdCBmdWxseSB1bmRlcnN0YW5kLCB0byBtYWtlIG15 c2VsZiBzb3VuZCBtb3JlIHBob3Rvc3ludGhlc2lzLiINCj4+IA0KPiANCg0K From nobody Fri Feb 10 06:30:40 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24070128B38; Fri, 10 Feb 2017 06:30:36 -0800 (PST) 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=unavailable 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 6qHmVOZc2N2v; Fri, 10 Feb 2017 06:30:34 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5214126DFB; Fri, 10 Feb 2017 06:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3228; q=dns/txt; s=iport; t=1486737033; x=1487946633; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yh68q7+yL2FoBgR5bneTSYAu41cN1Ub5ov5uRgevTkU=; b=gtBu7kbsYVuw7M90S5PL8tuZ7GZ8bFA57rVuJvsMfa4mjM/zrt5W3W5w z4pDUTwgUEmd37E/LWy2XqIIfYvgC4AxH7I8MxHTkdxKoS80lwt+OIP5j nvdC+ZU+tTX3sChZPPbrdfHFjvLXEya9FvHKv3A9CcMb2e639usXMN2NG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGAQA8zp1Y/5NdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygqgWoHg1KKCJIMlTaCDYYiAhqCXD8YAQIBAQEBAQEBYiiEaQE?= =?us-ascii?q?BAQMBIxE3BwcFCwIBCBgCAiYCAgIwFRACBA4FiXAIr1+CJYtRAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYELhUGCBYJqh1ougjEFm3IBkhOBe4UXiXOTFAEfOH5PFU0?= =?us-ascii?q?BhjB1iRKBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,141,1484006400"; d="scan'208";a="205035451" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2017 14:30:10 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v1AEU9B3016503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 14:30:09 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Feb 2017 09:30:08 -0500 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; Fri, 10 Feb 2017 09:30:08 -0500 From: "Carlos Pignataro (cpignata)" To: "Mirja Kuehlewind (IETF)" Thread-Topic: [Ioam] Internal WG Review: In-situ OAM (ioam) Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFf5E4AgAECTQCAAFm/gIABPEYAgAAnGQA= Date: Fri, 10 Feb 2017 14:30:08 +0000 Message-ID: References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> In-Reply-To: <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> 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.48.110] Content-Type: text/plain; charset="utf-8" Content-ID: <983AC63FABC27944B92EBEC5274DBE20@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "iesg@ietf.org" , "Alvaro Retana \(aretana\)" , The IAB , Spencer Dawkins at IETF , "ioam@ietf.org" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:30:36 -0000 SGksIE1pcmphLA0KDQpUaGlzIGlzIGEgZ29vZCBwb2ludCwgcGxlYXNlIHNlZSBpbmxpbmUuDQoN Cj4gT24gRmViIDEwLCAyMDE3LCBhdCA3OjEwIEFNLCBNaXJqYSBLdWVobGV3aW5kIChJRVRGKSA8 aWV0ZkBrdWVobGV3aW5kLm5ldD4gd3JvdGU6DQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBhbHNvIG9u ZSBtb3JlIGNvbW1lbnQgb24gdGhpcyBwb2ludDoNCj4gDQo+PiBBbSAwOS4wMi4yMDE3IHVtIDE4 OjE4IHNjaHJpZWIgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5j b20+Og0KPj4gDQo+Pj4+IElzIHRoZXJlIGFueSBjb25uZWN0aW9uIHdpdGggSVBQTT8NCj4+IA0K Pj4gWWVzLCB0aGVyZSBpcywgYXMgYWxyZWFkeSBtZW50aW9uZWQgYWJvdmUuDQo+IA0KPiANCj4g VGhlIGNoYXJ0ZXIgY3VycmVudGx5IHNheXM6DQo+IA0KPiAiT3RoZXIgb25nb2luZyBPQU0tcmVs YXRlZCBlZmZvcnRzIGluIHdvcmtpbmcgZ3JvdXBzKHMpIHN1Y2ggYXMgTVBMUyBhbmQNCj4gSVBQ TSB0aGF0IGRvIG5vdCBwaWdneWJhY2sgaW5mb3JtYXRpb24gb250byB0aGUgbGl2ZSB1c2VyIGRh dGEgdHJhZmZpYw0KPiBhcmUgb3V0IG9mIHNjb3BlIG9mIHRoZSBJT0FNIFdHLuKAnA0KDQpUaGUg SU9BTSB3b3JrIGlzIG5vdCBuYXJyb3dzY29wZWQgdG8gb25seSBQTS4gVGhpbmdzIGxpa2UgcGF0 aCB0cmFjaW5nIGFyZSBub3QgUE0uDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBJUFBNIGlzIG9ubHkg YWJvdXQgUE0sIGFuZCBpbiBmYWN0IGl0cyBjaGFydGVyIHN0YXJ0cyB3aXRoOg0K4oCcVGhlIElQ IFBlcmZvcm1hbmNlIE1ldHJpY3MgKElQUE0pIFdvcmtpbmcgR3JvdXAgZGV2ZWxvcHMgYW5kIG1h aW50YWlucw0Kc3RhbmRhcmQgbWV0cmljcyB0aGF0IGNhbiBiZSBhcHBsaWVkIHRvIHRoZSBxdWFs aXR5LCBwZXJmb3JtYW5jZSwgYW5kDQpyZWxpYWJpbGl0eSBvZiBJbnRlcm5ldCBkYXRhIGRlbGl2 ZXJ5IHNlcnZpY2VzIGFuZCBhcHBsaWNhdGlvbnMgcnVubmluZw0Kb3ZlciB0cmFuc3BvcnQgbGF5 ZXIgcHJvdG9jb2xzIChlLmcuIFRDUCwgVURQKSBvdmVyIElQLiINCg0KPiANCj4gd2hpY2ggaW5k aWN0YXRlcyB0aGF0IGNvb3BlcmF0aW9uIHdpdGggSVBQTSBpcyBub3QgcGxhbm5lZC4NCj4gDQoN CkkgdGhpbmsgdGhhdCB0aGlzIG91Z2h0IHRvIGJlIGZpeGVkL3JlZmluZWQsIGFuZCBJIGxpa2Ug dGhlIHNlbnRlbmNlIHRoYXQgRnJhbmsgcHJvcG9zZWQuDQoNClRoaXMgY29sbGFib3JhdGlvbiBp cyBpbXBvcnRhbnQuDQoNCj4gVG8gbWUgaW4gZ2VuZXJhbCB0aGUgcmVsYXRpb24gYmV0d2VlbiB0 aGlzIHdvcmsgYW5kIG90aGVyIG9uZ29pbmcgd29yayBpbiB0aGUgSUVURiBpcyBub3QgdmVyeSBj bGVhciBhbmQgSVBQTSBoYXMgc2V2ZXJhbCBkb2N1bWVudHMgYW5kIG1pbGVzdG9uZXMgdGhhdCBh cmUgaW4gc2NvcGUgZm9yIHRoaXMgd29yazoNCj4gDQo+IC0gU3VibWl0IGEgZHJhZnQgb24gdGhl IElQdjYgUGVyZm9ybWFuY2UgYW5kIERpYWdub3N0aWMgTWV0cmljcyAoUERNKSBEZXN0aW5hdGlv biBPcHRpb24gYXMgUHJvcG9zZWQgU3RhbmRhcmQ6IGRyYWZ0LWlldGYtaXBwbS02bWFuLXBkbS1v cHRpb24gKHRoaXMgZHJhZnQgaXMgbWFpbmx5IGRvbmUgYW5kIHNpbGVudGVyIHRoZSBwdWJsaWNh dGlvbiBwcm9jZXNzIHNvb24gdG8gbXkgdW5kZXJzdGFuZGluZykNCj4gDQo+IC0gU3VibWl0IGFu IEV4cGVyaW1lbnRhbCBkcmFmdCBvbiBjb2xvcmluZy1iYXNlZCBoeWJyaWQgbWVhc3VyZW1lbnQg bWV0aG9kb2xvZ2llcyBmb3IgbG9zcyBhbmQgZGVsYXkgdG8gdGhlIElFU0c6IGRyYWZ0LWlldGYt aXBwbS1hbHQtbWFyay0wMw0KPiANCj4gSSBkb27igJl0IHRoaW5rIHRoYXQgdGhlIGFzc2Vzc21l bnQgaW4gdGhlIGNoYXJ0ZXIgdGhhdCBJUFBNJ3Mgc2NvcGUgZG9lcyBub3QgaW5jbHVkZSBwaWdn eWJhY2tlZCBpbmZvcm1hdGlvbiBpcyBjb3JyZWN0LiBMb29raW5nIGF0IGRyYWZ0LWJyb2NrbmVy cy1pbmJhbmQtb2FtLXRyYW5zcG9ydC0wMiwgSSB0aGluayB0aGF0IGFueSB3b3JrIG9uIElQVjYg YW5kIElQdjYgaW4gdGhpcyBzY29wZSBzaG91bGQgYmUgZG9uZSBpbiBJUFBNIGJlY2F1c2UgdGhh dOKAmXMgd2VyZSB0aGlzIHdvcmsgaXMgYWxyZWFkeSBvbi1nb2luZyBhbmQgd2hlcmUgdGhlIG1l YXN1cmVtZW50IGV4cGVydGlzZSBpcy4NCj4gDQoNCkkgdGhpbmsgdGhhdCBJUFBNIGNhbiBsZXZl cmFnZSBJT0FNIGFuZCBpdHMgSVB2NiB0cmFuc3BvcnQgaW5zb2ZhcmFzIGRlZmluaW5nIFBNIG1l dGhvZHMuIEJ1dCBJT0FNID4gUE0uDQoNClRoYW5rcywNCg0K4oCUIENhcmxvcy4NCg0KPiBNaXJq YQ0KPiANCj4gDQo+IA0KPiANCg0K From nobody Fri Feb 10 06:49:05 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B64812999B; Fri, 10 Feb 2017 06:49:04 -0800 (PST) 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] 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 oLnFaDKunf6J; Fri, 10 Feb 2017 06:49:03 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5558129997; Fri, 10 Feb 2017 06:49:02 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1AEmv7V030435; Fri, 10 Feb 2017 14:48:57 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1AEmnXm030396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2017 14:48:55 GMT From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" , "'Stewart Bryant'" References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <4f16e222-97e4-6f87-e1a3-79115db8f355@gmail.com> <05a1d761-aed9-f62f-920b-93ed587a9fd4@gmail.com> <4E3165FB-0EFE-4784-8E3F-91538DED6110@cisco.com> In-Reply-To: <4E3165FB-0EFE-4784-8E3F-91538DED6110@cisco.com> Date: Fri, 10 Feb 2017 14:48:48 -0000 Message-ID: <0bd501d283ac$ce77d8a0$6b6789e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPa9VlOQLpUKVlo/4ITVNuqPkWhALz7hP3Abnb0PkCgVoGawGTqYkgAq+6G+cCeQ/v6QK4JAoMoONg+SA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22876.007 X-TM-AS-Result: No--18.392-10.0-31-10 X-imss-scan-details: No--18.392-10.0-31-10 X-TMASE-MatchedRID: csPTYAMX1+Etqx4vLVZ3FppWgCLYjjT9fkuZtv/FS5oahchoz+8vwqU3 V5yZ/yehKPLc4sLYU4OTqmwAJvD+yD4Pcn5OGAtGA9lly13c/gEK3iJpXUOQQ0uCjz4ggdtwAly Lcnl8KFTlDcI3iQId6PfNoIn4zO79JO0KFVwm0Tgy0WOtNS62pGGNLTRnb5YtG0N1z/ycuLKQox Dk18vskRI4uaCmyvSK3REoni7NqN4M8jMXjBF+sIMbH85DUZXy3QfwsVk0UbslCGssfkpInQ== Archived-At: Cc: "'Alvaro Retana \(aretana\)'" , 'The IAB' , ioam@ietf.org, iesg@ietf.org, 'Spencer Dawkins at IETF' Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:49:04 -0000 [snip] > > I have not thought it through, but I am wondering what distinguishes = the > > packet types you list (IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, = Geneve) from > > other packet types, the obvious one being MPLS. Not that I am at all = keen on > > trying to get this into the simple fast forwarders we use for MPLS. = In other words > > what is the generic class of packets you are targetting? >=20 > Encapsulations? I *think* I read this as Carlos saying... We want to define a layer-independent, encapsulation-independent generic = data format for carrying any OAM information in user data packets. We = expect this to be useful in the following list of forwarding = encapsulations but the actual use of and encapsulation of = this generic data format will be worked on in coordination with the = working groups responsible for those encapsulations. This, to me, seems similar to the approach taken by the SFC working = group. The generic format is agnostic to (ignorant of?) both the = encapsulation and the type of data carried. In a sense, of course, it means that it is possible that the generic = data format will be invented, but never used (because no group = responsible for a forwarding encapsulation thinks IOAM is appropriate or = desirable). Although I suspect that Carlos and frank have ambitions in = this area :-) I would certainly like the charter to be more clear about what is being = built (the final paragraph does cover some of this, but the generic = nature is not as obvious as it should be). Adrian From nobody Fri Feb 10 06:50:55 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512BC129987; Fri, 10 Feb 2017 06:50:50 -0800 (PST) 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=unavailable 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 DkSHncupv5Lw; Fri, 10 Feb 2017 06:50:48 -0800 (PST) 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 90BAB129988; Fri, 10 Feb 2017 06:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11570; q=dns/txt; s=iport; t=1486738247; x=1487947847; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5hwrazJ6tfe5lUQDU3jKjg5seHZbS2rzeAcfE7wDh3g=; b=mnpvdnqM0OlWghnr5gZgADl7Zn5agZ2toRIIyFIudyy/nYEmG5y1wBDW OWGD8mzInYyk/OX2z0YP0r5PyJ89KmHAklI+VUZqZQx46Dcv+G1gvaV01 2CA3wcpqz8ZDkAd/9EfoxDTlMVWPOIbP28RTatCRJJj1W14fguBljo4wW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAQB80p1Y/4cNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1JheBEHg1KKCJFtH4gMjSqCDR8LgkKDNgIagl0/GAECAQEBAQE?= =?us-ascii?q?BAWIohGkBAQEDAQEBIREzBwsFCwIBCBgCAggeAgICHwYLFRACBA4FiWADDQgOr?= =?us-ascii?q?16CJYc2DYQOAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VBggUIgmKCUYFmAQE?= =?us-ascii?q?ygm8ugjEFiQyMSIVkOgGGbocMhBmBe4UXiXOILIIJiF8BHzh+TxU8EQGEMh2BY?= =?us-ascii?q?XUBh3CBIYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.35,141,1484006400"; d="scan'208";a="210192061" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2017 14:50:46 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1AEokQ5001757 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 14:50:46 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Feb 2017 09:50:45 -0500 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; Fri, 10 Feb 2017 09:50:44 -0500 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" Thread-Topic: [Ioam] Internal WG Review: In-situ OAM (ioam) Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFhgq0A///ULoCAAVKhgA== Date: Fri, 10 Feb 2017 14:50:44 +0000 Message-ID: <30D731F6-7073-486B-9395-BF1FC31F004C@cisco.com> References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <87206d4b-9b2c-f44c-754c-628e8c8e8887@cs.tcd.ie> 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.150.48.110] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ioam@ietf.org" , "iesg@ietf.org" , The IAB , Stephen Farrell Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:50:50 -0000 SGksIFN0ZXBoZW4sDQoNClRoZXNlIGFyZSBpbXBvcnRhbnQgcXVlc3Rpb25zIOKAlCBwbGVhc2Ug ZmluZCBzb21lIGVhcmx5IHRob3VnaHRzIGlubGluZS4NCg0KPiBPbiBGZWIgOSwgMjAxNywgYXQg NTozOCBQTSwgQWx2YXJvIFJldGFuYSAoYXJldGFuYSkgPGFyZXRhbmFAY2lzY28uY29tPiB3cm90 ZToNCj4gDQo+IFN0ZXBoZW46DQo+ICANCj4gSGkhDQo+ICANCj4gSSB0aGluayB0cmlja3ksIGJ1 dCBpbXBvcnRhbnQuICBJ4oCZbSBjY+KAmWluZyB0aGUgbGlzdCB0byBnZXQgdGhlIGFuc3dlcnMg dGhlcmUuDQo+ICANCj4gVG8geW91ciBzZWNvbmQgcXVlc3Rpb24uICBZZXMsIHRoZXJlIGNsZWFy bHkgaXMgYW4gZXhwZWN0YXRpb24gb24gdGhlIG91dGNvbWUsIGlmIElQdjYgaXMgdXNlZCBhcyBh biBlbmNhcHN1bGF0aW5nIHByb3RvY29sLiAgQnV0IHRoYXQgaXMgbm90IHRoZSBvbmx5IGFwcGxp Y2F0aW9uLg0KPiAgDQo+IFRoYW5rcyENCj4gIA0KPiBBbHZhcm8uDQo+ICANCj4+IE9uIDIvOS8x NywgMzoxNSBQTSwgImllc2cgb24gYmVoYWxmIG9mIFN0ZXBoZW4gRmFycmVsbCIgPGllc2ctYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2ZzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiB3cm90 ZToNCj4+ICANCj4+ICANCj4+IEhpeWEsDQo+PiAgDQo+PiBJIGhhdmUgdHdvIHBvc3NpYmx5IHRy aWNreSBxdWVzdGlvbnMgYWJvdXQgdGhpczoNCj4+ICANCj4+IDEpIEknbSBzdXJlIHRoZXJlIGFy ZSBnb29kIHRoaW5ncyBvbmUgY2FuIGRvIHdpdGggc3VjaA0KPj4gbWFya2luZywgYnV0IGl0IGlz IHZlcnkgdW5jbGVhciB0byBtZSBob3cgdGhpcyBwcm9wb3NhbA0KPj4gZG9lc24ndCBhbHNvIGZh bGwgYWZvdWwgb2YgYWxsIHRoZSBwcml2YWN5IGRvd25zaWRlcyBvZg0KPj4gdGhlIFNQVUQvUExV UyBwcm9wb3NhbC4gTXkgdW5kZXJzdGFuZGluZyBvZiB0aG9zZSBwcml2YWN5DQo+PiBkb3duc2lk ZXMgd2FzIHRoYXQgYW55IGdlbmVyaWMvZXh0ZW5zaWJsZSBtYXJraW5nIHNjaGVtZQ0KPj4gKHdo ZXRoZXIgb2YgcGFja2V0cyBvciB0cmFuc3BvcnQgY29ubmVjdGlvbnMvZmxvd3MpIGNvdWxkDQo+ PiBlYXNpbHkgYmUgYWJ1c2VkIGluIG1hbnkgcHJpdmFjeSB1bmZyaWVuZGx5IHdheXMuIE5vdGUN Cj4+IHRoYXQgSSdtIG5vdCBjbGFpbWluZyB0aGVyZSBpcyBJRVRGIGNvbnNlbnN1cyBvbiB0aGF0 DQo+PiBidXQgSSBkbyBjbGFpbSBpdCB3YXMgYSBzaWduaWZpY2FudCBpc3N1ZSBmb3IgU1BVRC9Q TFVTDQo+PiBhbmQgd291bGQgbGlrZSB0byBrbm93IHdoeSAoYW5kIGhvcGUpIGl0IGlzIG5vdCBh biBpc3N1ZQ0KPj4gaGVyZS4gQ2FuIHNvbWVvbmUgaGVscCBtZSB1bmRlcnN0YW5kIHdoYXQncyBk aWZmZXJlbnQgaGVyZQ0KPj4gc28gd2UgYXZvaWQgdGhhdCBzYW1lIGtpbmQgb2YgbWVnYS1kZWJh dGU/DQo+PiAgDQoNCk5vdGUgdGhhdCB0aGlzIHByb3Bvc2FsIGNvbmNlcm5zIGl0c2VsZiB3aXRo IE9BTSBpbmZvcm1hdGlvbiwgYW5kIG5vdCBhcyBhIGdlbmVyaWMgY29udGFpbmVyIGZvciBhbGwt dGhpbmdzLiBJdCBpcyBub3QgZm9yIGFwcGxpY2F0aW9uIGluZm9ybWF0aW9uLg0KDQpGdXJ0aGVy LCBhcyBwZXIgaXRzIGNoYXJ0ZXIsIGl0IGlzIGFsc28gY29uc3RyYWluZWQgaW4gZGVwbG95bWVu dCBhbmQgbm90IGEgZnVsbCBJbnRlcm5ldCBzY29wZTog4oCcIEluLVNpdHUgT0FNIG9wZXJhdGlv bnMgYXJlIGRlZmluZWQgZm9yIGEgc3BlY2lmaWMgb3BlcmF0aW9uYWwgZG9tYWluLiINCg0KVGhh dCBzYWlkLCBJIGFtIG5vdCB0b28gZmFtaWxpYXIgd2l0aCB0aGUgZGVwdGhzIG9mIHRoZSBTUFVE L1BMVVMgZGViYXRlIG9yIGl0cyBvdXRjb21lcy4gQ2FuIHlvdSBzaGFyZSBzb21lIHBvaW50ZXJz IG9yIGV4cGxhaW4gaG93IHlvdSBzZWUgdGhlIGludGVyc2VjdGlvbiBvciBjb25jZXJuPw0KDQo+ PiAyKSBUaGVyZSBpcyBhbiBvbmdvaW5nIGFuZCBzZWVtaW5nbHkgdmVyeSBoYXJkIHRvIHJlc29s dmUNCj4+IGRpc2N1c3Npb24gWzFdIG9uIGlldGZAaWV0Zi5vcmcgaW4gd2hpY2ggYSBkcmFmdCBy ZWxhdGVkIHRvDQo+PiB0aGlzIHByb3Bvc2FsIGhhcyBiZWVuIHF1b3RlZCBbMl0gYXMgZXZpZGVu Y2Ugb24gb25lIHNpZGUNCj4+IG9mIHRoZSBhcmd1bWVudC4gSSdtIG5vdCBjbGVhciB0aGF0IHdl IHNob3VsZCBnbyBhaGVhZCB3aXRoDQo+PiB0aGlzIGNoYXJ0ZXIgYmVmb3JlIHdlIGhhdmUgZXN0 YWJsaXNoZWQgSUVURiBjb25zZW5zdXMNCj4+IG9uZSB3YXkgb3IgYW5vdGhlciBhYm91dCB3aGF0 IHdlIHRoaW5rIGFib3V0IFsxXSAoYnkgd2hpY2gNCj4+IEkgc3BlY2lmaWNhbGx5IG1lYW4gdGhl IGlzc3VlIG9mIGhlYWRlcnMgYmVpbmcgcHJvY2Vzc2VkDQo+PiBhd2F5IGZyb20gdGhlIGVuZHBv aW50cykuIElmIEknbSByaWdodCB0aGF0IHRoZXNlIGFyZQ0KPj4gcmVsYXRlZCAoYW5kIGl0J3Mg cG9zc2libGUgSSdtIGVudGlyZWx5IHdyb25nOy0pIHRoZW4gSQ0KPj4gZ3Vlc3MgZGVwZW5kaW5n IG9uIHRoZSBvdXRjb21lIG9mIFsxXSB0aGF0J2QgZWl0aGVyIG1lYW4NCj4+IGEgc2hvcnQgZGVs YXkgZm9yIHRoaXMsIG9yIGVsc2UgYSBuZWVkIGZvciBzb21lIG1ham9yDQo+PiBjaGFuZ2UgYW5k IHRoYXQgcmlzayB3b3VsZCBzZWVtIHRvIG1lIHRvIGp1c3RpZnkgbm90DQo+PiBmb3JnaW5nIGFo ZWFkIHdpdGggdGhpcyBqdXN0IHlldC4gU28gdGhlIHF1ZXN0aW9uIGlzOg0KPj4gYW0gSSByaWdo dCB0aGF0IHRoaXMgcHJvcG9zYWwgYXNzdW1lcyBvbmUgb3V0Y29tZSBvZg0KPj4gdGhlIGRpc2N1 c3Npb24gYWJvdXQgaGVhZGVyIHByb2Nlc3NpbmcgaW4gWzFdPw0KPj4gIA0KDQpUaGlzIHByb3Bv c2FsIGRvZXMgbm90IGFzc3VtZSBvbmUgb3V0Y29tZSwgbm9yIGl0IHBsYWNlcyBhIGRlcGVuZGVu Y3kgb24gb25lLiBUaGlzIHByb3Bvc2FsIGFpbXMgYXQgYSBudW1iZXIgb2YgZW5jYXBzdWxhdGlv bnMsIG9uZSBvZiB3aGljaCBpcyBJUHY2Lg0KDQpUaGFua3MhDQoNCuKAlCBDYXJsb3MuDQoNCj4+ IENoZWVycywNCj4+IFMuDQo+PiAgDQo+PiBQUzogSSdtIGZpbmUgdG8gYXNrIHRoZXNlIHR3byBx dWVzdGlvbnMgaW4gYSBiYWxsb3QgaWYgdGhhdCdzDQo+PiBiZXR0ZXIuIEJ1dCBhdCB0aGUgbW9t ZW50IHRoYXQnZCBsaWtlbHkgYmUgYSBCTE9DSyBiYWxsb3QNCj4+IHNvIEkgd2FudGVkIHRvIGNo ZWNrIGZpcnN0IGlmIEknbSBvZmYgYmFzZSwgYXMgaGFwcGVucyBub3cNCj4+IGFuZCB0aGVuOi0p DQo+PiAgDQo+PiAgDQo+PiBbMV0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9pZXRmL2N1cnJlbnQvbXNnMTAwOTYwLmh0bWwNCj4+IFsyXSBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL2lldGYvY3VycmVudC9tc2cxMDEwMTIuaHRtbA0KPj4gIA0KPj4g IA0KPj4gT24gMDgvMDIvMTcgMTg6MzIsIElFVEYgU2VjcmV0YXJpYXQgd3JvdGU6DQo+Pj4gQSBu ZXcgSUVURiBXRyBpcyBiZWluZyBjb25zaWRlcmVkIGluIHRoZSBJRVRGLiBUaGUgZHJhZnQgY2hh cnRlciBmb3IgdGhpcw0KPj4+IFdHIGlzIHByb3ZpZGVkIGJlbG93IGZvciB5b3VyIHJldmlldyBh bmQgY29tbWVudC4NCj4+PiBSZXZpZXcgdGltZSBpcyBvbmUgd2Vlay4NCj4+PiBUaGUgSUVURiBT ZWNyZXRhcmlhdA0KPj4+IEluLXNpdHUgT0FNIChpb2FtKQ0KPj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ Pj4gQ3VycmVudCBzdGF0dXM6IFByb3Bvc2VkIFdHDQo+Pj4gQ2hhaXJzOg0KPj4+ICAgIFRCRA0K Pj4+IEFzc2lnbmVkIEFyZWEgRGlyZWN0b3I6DQo+Pj4gICAgQWx2YXJvIFJldGFuYSA8YXJldGFu YUBjaXNjby5jb20+DQo+Pj4gUm91dGluZyBBcmVhIERpcmVjdG9yczoNCj4+PiAgICBBbGlhIEF0 bGFzIDxha2F0bGFzQGdtYWlsLmNvbT4NCj4+PiAgICBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hQGNp c2NvLmNvbT4NCj4+PiAgICBEZWJvcmFoIEJydW5nYXJkIDxkYjM1NDZAYXR0LmNvbT4NCj4+PiAg IA0KPj4+IE1haWxpbmcgbGlzdDoNCj4+PiAgICBBZGRyZXNzOiBpb2FtQGlldGYub3JnDQo+Pj4g ICAgVG8gc3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lv YW0NCj4+PiAgICBBcmNoaXZlOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJv d3NlL2lvYW0vDQo+Pj4gQ2hhcnRlcjogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv Y2hhcnRlci1pZXRmLWlvYW0vDQo+Pj4gSW4tc2l0dSBPQU0gcHJvdmlkZXMgcmVhbC10aW1lIHRl bGVtZXRyeSBvZiBpbmRpdmlkdWFsIGRhdGEgcGFja2V0cyBhbmQNCj4+PiBmbG93cy4gSXQgaXMg YmFzZWQgb24gdGVsZW1ldHJ5IGluZm9ybWF0aW9uIHdoaWNoIGlzIGVtYmVkZGVkIHdpdGhpbiBs aXZlDQo+Pj4gZGF0YSBwYWNrZXRzLiBUaGUgSU9BTSBXRyBpbnRlbmRzIHRvIGRlZmluZSBkYXRh IGZvcm1hdHMgYW5kIGFzc29jaWF0ZWQNCj4+PiBwcm9jZWR1cmVzIGZvciBpbi1zaXR1IE9BTSwg aW5jbHVkaW5nIG1lY2hhbmlzbXMgZm9yIGNhcHR1cmluZyBwYXRoIGFuZA0KPj4+IHBhdGgtdHJh dmVyc2FsIHJlbGF0ZWQgaW5mb3JtYXRpb24gYXMgd2VsbCBhcyBwcm9jZWR1cmVzIHRvIGVtcGxv eSwNCj4+PiBjb25maWd1cmUsIHRyaWdnZXIsIGFuZCBleHBvcnQgdGhlIGVtYmVkZGVkIHRlbGVt ZXRyeSBpbmZvcm1hdGlvbi4NCj4+PiAgIA0KPj4+IFRoZSBJT0FNIFdHIHdpbGwgZGVmaW5lIHRo ZSBmb2xsb3dpbmcgaW4tc2l0dSBPQU0gY29tcG9uZW50czoNCj4+PiAgIA0KPj4+ICogRGF0YS1y ZWNvcmRzIGZvciBpbi1zaXR1IE9BTSB0byBjb3ZlciBwYXRoLXRyYWNpbmcgYW5kIHBhdGgNCj4+ PiB2ZXJpZmljYXRpb24gaW5mb3JtYXRpb24gKG5vZGUtaWRzLCBpbmdyZXNzL2VncmVzcyBpbnRl cmZhY2VzKSwNCj4+PiB0aW1lc3RhbXBzLCB0cmFuc2l0LWRlbGF5LCB0cmFuc2l0IGppdHRlciwg c2VxdWVuY2UgbnVtYmVycywNCj4+PiBhcHBsaWNhdGlvbi1kZWZpbmVkIG1ldGFkYXRhLiBJbi1z aXR1IE9BTSBkYXRhLXJlY29yZHMgYXJlIGRlZmluZWQgdXNpbmcNCj4+PiBhbiBpbi1zaXR1IE9B TSBuYW1lc3BhY2UuIEl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBjb250cm9sIHRoZQ0KPj4+IGlu Zm9ybWF0aW9uIHRoYXQgZ2V0cyByZWNvcmRlZCBpbiBkYXRhLXJlY29yZHMuDQo+Pj4gKiBQcm9j ZWR1cmVzIHRvIGFkZCwgdXBkYXRlLCByZW1vdmUsIHJldHJpZXZlIGFuZCBleHBvcnQgZGF0YS1y ZWNvcmRzIGZvcg0KPj4+IGluLXNpdHUgT0FNIHRvIGxpdmUgdHJhZmZpYyBhbmQgYWN0aXZlIHBy b2JpbmcuICBJbiBjYXNlIG9mIGxpdmUgdHJhZmZpYw0KPj4+IGEgY2xhc3NpZmllciB0byBzZWxl Y3Qgc3Vic2V0IG9mIGxpdmUgdHJhZmZpYyBmb3IgYWRkaXRpb24sIHVwZGF0ZSwNCj4+PiByZW1v dmFsIGFuZCByZXRyaWV2YWwgb2YgaW4tc2l0dSBPQU0gZGF0YS1yZWNvcmRzLiBJbiBjYXNlIG9m IGFjdGl2ZQ0KPj4+IHByb2JpbmcgcHJvY2VkdXJlIHRvIHJldHVybiB0aGUgaW4tc2l0dSBPQU0g ZGF0YSByZWNvcmRzIHRvIHRoZSBzb3VyY2Ugb2YNCj4+PiB0aGUgcHJvYmUuDQo+Pj4gKiAgU2Nv cGUgb2YgaW4tc2l0dSBPQU0gb3BlcmF0aW9uLiBJbi1TaXR1IE9BTSBvcGVyYXRpb25zIGFyZSBk ZWZpbmVkIGZvcg0KPj4+IGEgc3BlY2lmaWMgb3BlcmF0aW9uYWwgZG9tYWluLiBJbi1zaXR1IE9B TSBkYXRhLXJlY29yZHMgYXJlIGFkZGVkIGFuZA0KPj4+IHJlbW92ZWQgYXQgZG9tYWluIGJvdW5k YXJpZXMgYW5kIHVwZGF0ZWQgYnkgbm9kZXMgd2l0aGluIHRoZSBpbi1zaXR1IE9BTQ0KPj4+IGRv bWFpbi4gUHJvY2VkdXJlIHRvIGRlYWwgd2l0aCB2YXJpb3VzIGNoYWxsZW5nZXMgaW4gcGFja2V0 IGZvcndhcmRpbmcNCj4+PiBhbmQgZXJyb3IgaGFuZGxpbmcgc3VjaCBhcyBFQ01QIHByb2Nlc3Np bmcsIHBhdGggTVRVIGFuZCBJQ01QIG1lc3NhZ2UNCj4+PiBoYW5kbGluZyB3aGVuIGluLXNpdHUg T0FNIGlzIGVuYWJsZWQgaW4gYW4gaW4tc2l0dSBPQU0gZG9tYWluLg0KPj4+ICogIERhdGEtcmVj b3JkcyBmb3IgaW4tc2l0dSBPQU0gYXJlIHRvIGJlIGRlZmluZWQgaW4gYSB3YXkgdGhhdCBtYWtl cw0KPj4+IHRoZW0gaW5kZXBlbmRlbnQgZnJvbSB0aGUgdHJhbnNwb3J0IHByb3RvY29sIHVzZWQu IERhdGEtcmVjb3JkcyBmb3INCj4+PiBpbi1zaXR1IE9BTSB3aWxsIG5lZWQgdG8gYmUgZW1iZWRk ZWQgaW50byB0cmFuc3BvcnQgcHJvdG9jb2xzIHN1Y2ggYXMNCj4+PiBJUHY0LCBJUHY2LCBWWExB Ti1HUEUsIExJU1AsIE5TSCwgU1J2NiwgR2VuZXZlLg0KPj4+ICogUHJvY2VkdXJlcyBhbmQgZGF0 YS1yZWNvcmRzIG9wdGltaXplZCBmb3Igc29mdHdhcmUgZGF0YXBsYW5lIGFuZA0KPj4+IGhhcmR3 YXJlIGRhdGFwbGFuZSBpbXBsZW1lbnRhdGlvbnMgb2YgaW4tc2l0dSBPQU0uDQo+Pj4gKiBJbi1z aXR1IE9BTSB0byBzdXBwb3J0IGxheWVyaW5nLiBJZiBzZXZlcmFsIHRyYW5zcG9ydCBwcm90b2Nv bHMgKGUuZy4NCj4+PiBpbiBjYXNlIG9mIHR1bm5lbGluZykgYXJlIHN0YWNrZWQgb24gdG9wIG9m IGVhY2ggb3RoZXIsIGluLXNpdHUgT0FNDQo+Pj4gZGF0YS1yZWNvcmRzIGNvdWxkIGJlIHByZXNl bnQgaW4gZXZlcnkgdHJhbnNwb3J0IHByb3RvY29sIGxheWVyLg0KPj4+ICogTWFuYWdlbWVudCBh bmQgY29udHJvbCBvZiByb2xlIG9mIG5vZGVzIGZvciBpbi1zaXR1IE9BTSBvcGVyYXRpb24sDQo+ Pj4gZHluYW1pYyBjb250cm9sIG9mIGluLXNpdHUgT0FNIGRhdGEgY29sbGVjdGVkIGluIHRoZSBk YXRhIHJlY29yZHMsIGRhdGENCj4+PiBleHBvcnQgb3B0aW1pemF0aW9uLg0KPj4+ICAgDQo+Pj4g VGhlIElPQU0gd29ya2luZyBncm91cCBpbnRlbmRzIHRvIHdvcmsgb24gYW5kIHB1Ymxpc2g6DQo+ Pj4gKiBEZWZpbml0aW9uIG9mIHRoZSBkYXRhLXR5cGUgZm9ybWF0cyB1c2VkIGluIGluLXNpdHUg T0FNIGFuZCBuYW1lc3BhY2VzDQo+Pj4gZm9yIGluLXNpdHUgT0FNLg0KPj4+ICogRGVmaW5pdGlv biBvZiBwcm9jZWR1cmVzIHRoYXQgaW4tc2l0dSBPQU0gZW5hYmxlZCBub2RlcyB3aWxsIHBlcmZv cm0gb24NCj4+PiBkYXRhIHRyYWZmaWMgdGhhdCBjYXJyaWVzIGluLXNpdHUgT0FNIGluZm9ybWF0 aW9uIChlLmcuLCBpbnRyb2R1Y2luZywNCj4+PiByZW1vdmluZywgcHJvY2Vzc2luZywgbW9kaWZ5 aW5nLCBhbmQgZXhwb3J0aW5nIHRoZSB0ZWxlbWV0cnkgaW5mb3JtYXRpb24NCj4+PiBmcm9tIHRo ZSBhc3NvY2lhdGVkIGRhdGEgcGFja2V0cykuDQo+Pj4gKiBDb25maWd1cmF0aW9uIGFuZCBvcGVy YXRpb25hbCBkYXRhIG1vZGVscyBmb3IgY29udHJvbGxpbmcgaW4tc2l0dSBPQU0NCj4+PiBkYXRh IGFuZCBvcGVyYXRpb25zLg0KPj4+IEluLXNpdHUgT0FNIGRhdGEgcmVjb3JkcyBjb3VsZCBiZSBl bWJlZGRlZCBpbnRvIGEgdmFyaWV0eSBvZiB0cmFuc3BvcnRzLg0KPj4+IFRoZSB0cmFuc3BvcnRz IGFyZSBleHBlY3RlZCB0byBiZSBkZWZpbmVkIGluIHRoZSByZXNwZWN0aXZlIHdvcmtpbmcNCj4+ PiBncm91cChzKSBsaWtlIE5WTzMsIFNGQywgNm1hbiwgTVBMUyBldGMgaW4gY29uc3VsdGF0aW9u IHdpdGggdGhlIElPQU0NCj4+PiB3b3JraW5nIGdyb3VwIGRvY3VtZW50cy4gSU9BTSBXRyBleGNs dXNpdmVseSBmb2N1c2VzIG9uIG1lY2hhbmlzbXMgd2hpY2gNCj4+PiBwaWdneWJhY2sgT0FNLXJl bGF0ZWQgbWV0YWRhdGEgb250byBlbi1yb3V0ZSB0cmFmZmljIGZvciBPQU0gcHVycG9zZXMuDQo+ Pj4gT3RoZXIgb25nb2luZyBPQU0tcmVsYXRlZCBlZmZvcnRzIGluIHdvcmtpbmcgZ3JvdXBzKHMp IHN1Y2ggYXMgTVBMUyBhbmQNCj4+PiBJUFBNIHRoYXQgZG8gbm90IHBpZ2d5YmFjayBpbmZvcm1h dGlvbiBvbnRvIHRoZSBsaXZlIHVzZXIgZGF0YSB0cmFmZmljDQo+Pj4gYXJlIG91dCBvZiBzY29w ZSBvZiB0aGUgSU9BTSBXRy4NCj4+PiAgIA0KPj4+IE1pbGVzdG9uZXMNCj4+PiAgIA0KPj4+IEFw cmlsIDIwMTggLSBzdWJtaXQgZGF0YSBmb3JtYXQgYW5kIGFzc29jaWF0ZWQgcHJvY2VkdXJlcyBk b2N1bWVudCB0bw0KPj4+IElFU0cuDQo+Pj4gTWFyY2ggMjAxOCAtIFdHTEMgZm9yIGRhdGEgZm9y bWF0IGFuZCBhc3NvY2lhdGVkIHByb2NlZHVyZXMgZG9jdW1lbnQuDQo+Pj4gQXByaWwgMjAxNyAt IHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gb2YgZGF0YSBmb3JtYXQgYW5kIGFzc29jaWF0ZWQNCj4+ PiBwcm9jZWR1cmVzIGRvY3VtZW50DQo+Pj4gTWlsZXN0b25lczoNCj4+ICANCj4+ICANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSW9hbSBtYWls aW5nIGxpc3QNCj4gSW9hbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lvYW0NCg0K From nobody Fri Feb 10 07:04:47 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4DD1299AF; Fri, 10 Feb 2017 07:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable 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 PeG8sPjn7cmj; Fri, 10 Feb 2017 07:04:41 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D5A1299AD; Fri, 10 Feb 2017 06:58:22 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1AEwFxh032339; Fri, 10 Feb 2017 14:58:15 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1AEwAtW032329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2017 14:58:13 GMT From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" , "'Alvaro Retana \(aretana\)'" References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <87206d4b-9b2c-f44c-754c-628e8c8e8887@cs.tcd.ie> <30D731F6-7073-486B-9395-BF1FC31F004C@cisco.com> In-Reply-To: <30D731F6-7073-486B-9395-BF1FC31F004C@cisco.com> Date: Fri, 10 Feb 2017 14:58:10 -0000 Message-ID: <0be201d283ae$1b120680$51361380$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPa9VlOQLpUKVlo/4ITVNuqPkWhAIITfo/Aao35ZECviEHQaE0/hqQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22876.007 X-TM-AS-Result: No--4.185-10.0-31-10 X-imss-scan-details: No--4.185-10.0-31-10 X-TMASE-MatchedRID: oTBA/+sdKaY4HKI/yaqRm521GZGE81yGQKuv8uQBDjocVJCT3tVgammu O+SIU9jShrPMo8WhIm/+9/p0ze6ZW7nuANUvLzt6gHYvFG2GAiuh116jcOfAC4PwsVfJeRq1/Ge vfoH427rg2LxpMMc9P9zCr6SJuyZAiZ2qmNOTCPHTzWmGCXkX+QsE9gx+4jJuJPWmj2u7bITZ+2 //mNeSL5e5gnMF6wnFrxJD3ongg+a77rpLLmM7AlVN8laWo90MkZs6eeBnIM2bKItl61J/yZkw8 KdMzN86KrauXd3MZDVepfvh/AFWPQD063mkwejQqlJLQb+owWLNccZBz3lmmCUk9XSHzudJu69u NLdownRfecGEXGiUYsUpahg/gRz10yN3EhwURBWPT695Jh3P26fItuohgjfnw/3NmPJsa4pNWfn UnboML1TXUX0dTQdP Archived-At: Cc: ioam@ietf.org, iesg@ietf.org, 'The IAB' , 'Stephen Farrell' Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 15:04:42 -0000 > >> 1) I'm sure there are good things one can do with such > >> marking, but it is very unclear to me how this proposal > >> doesn't also fall afoul of all the privacy downsides of > >> the SPUD/PLUS proposal. My understanding of those privacy > >> downsides was that any generic/extensible marking scheme > >> (whether of packets or transport connections/flows) could > >> easily be abused in many privacy unfriendly ways. Note > >> that I'm not claiming there is IETF consensus on that > >> but I do claim it was a significant issue for SPUD/PLUS > >> and would like to know why (and hope) it is not an issue > >> here. Can someone help me understand what's different here > >> so we avoid that same kind of mega-debate? >=20 > Note that this proposal concerns itself with OAM information, and not = as a > generic container for all-things. It is not for application = information. Hmmm. Once you define a channel to carry other stuff along with data packets = it will be used for purposes as yet undreamed of. To give you a hint... The SFC's NSH can carry metadata along with data packets in order that = service functions can coordinate their actions and receive hints from = packet classifiers. A recent question was... Suppose an application that s sourcing packets wishes to communicate = with an application receiving those packets in order to explain how the = packets should be treated. Could it use the NSH and put information in = the metadata even though there is no service function chain involved and = no service functions on the path? So, if you open a channel, it will be used. Will it also provide a covert channel? Who can say? Adrian From nobody Fri Feb 10 07:05:51 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0301299AB; Fri, 10 Feb 2017 07:05:46 -0800 (PST) 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 vuoZ9fGvZOmr; Fri, 10 Feb 2017 07:05:45 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DEDB1299AD; Fri, 10 Feb 2017 07:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3642; q=dns/txt; s=iport; t=1486739145; x=1487948745; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dj6nBhr2eoiBly5luvvFrGYLHC5Y9olP5b9gNO6NeP0=; b=MLMm1L3u7AYO4qFEfTYeWs/959R9wxqUw2z8IzadKXaYqSKjbDtKhIGw Mnb2hB+fG76Ww+M/xNmuasSgb1L7T7OOKYaabvq9vTQttp312v6c177fi fACsCzsph/2GPYeo3Us+BzkP2h4+FO3NCO8B7M0LkTKcDD9qeou8jHnWT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AwDA1Z1Y/5xdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1KBageDUpt1H5U2gg2GIgIagl5BFgECAQEBAQEBAWIohGkBAQE?= =?us-ascii?q?DASMRMxIFCwIBCBgCAiYCAgIwFRACBA4FiXAIr2+CJYtPAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEegQuFQYIFCIJihFSDBi6CMQWPQ4YRhh4BkhOBe4hnhiOTFAEmCyZ?= =?us-ascii?q?+TxU8EQGEMh2BYXWJEoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.35,141,1484006400"; d="scan'208";a="383882343" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2017 15:05:44 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v1AF5i32009179 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 15:05:44 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Feb 2017 10:05:43 -0500 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; Fri, 10 Feb 2017 10:05:43 -0500 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel Thread-Topic: [Ioam] Internal WG Review: In-situ OAM (ioam) Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFf5E4AgAECTQCAAFm/gIAAGdcAgAALP4CAAOsigIAAUJoAgAAHxACAAAS6gA== Date: Fri, 10 Feb 2017 15:05:43 +0000 Message-ID: References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <4f16e222-97e4-6f87-e1a3-79115db8f355@gmail.com> <05a1d761-aed9-f62f-920b-93ed587a9fd4@gmail.com> <4E3165FB-0EFE-4784-8E3F-91538DED6110@cisco.com> <0bd501d283ac$ce77d8a0$6b6789e0$@olddog.co.uk> In-Reply-To: <0bd501d283ac$ce77d8a0$6b6789e0$@olddog.co.uk> 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.48.110] Content-Type: text/plain; charset="utf-8" Content-ID: <3312445C06194642BA9F8CB11C5D3E24@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ioam@ietf.org" , Spencer Dawkins at IETF , "Alvaro Retana \(aretana\)" , Stewart Bryant , The IAB , The IESG Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 15:05:47 -0000 SGksIEFkcmlhbiwNCg0KDQo+IE9uIEZlYiAxMCwgMjAxNywgYXQgOTo0OCBBTSwgQWRyaWFuIEZh cnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az4gd3JvdGU6DQo+IA0KPiBbc25pcF0NCj4gDQo+Pj4g SSBoYXZlIG5vdCB0aG91Z2h0IGl0IHRocm91Z2gsIGJ1dCBJIGFtIHdvbmRlcmluZyB3aGF0IGRp c3Rpbmd1aXNoZXMgdGhlDQo+Pj4gcGFja2V0IHR5cGVzIHlvdSBsaXN0IChJUHY0LCBJUHY2LCBW WExBTi1HUEUsIExJU1AsIE5TSCwgU1J2NiwgR2VuZXZlKSBmcm9tDQo+Pj4gb3RoZXIgcGFja2V0 IHR5cGVzLCB0aGUgb2J2aW91cyBvbmUgYmVpbmcgTVBMUy4gTm90IHRoYXQgSSBhbSBhdCBhbGwg a2VlbiBvbg0KPj4+IHRyeWluZyB0byBnZXQgdGhpcyBpbnRvIHRoZSBzaW1wbGUgZmFzdCBmb3J3 YXJkZXJzIHdlIHVzZSBmb3IgTVBMUy4gSW4gb3RoZXIgd29yZHMNCj4+PiB3aGF0IGlzIHRoZSBn ZW5lcmljIGNsYXNzIG9mIHBhY2tldHMgeW91IGFyZSB0YXJnZXR0aW5nPw0KPj4gDQo+PiBFbmNh cHN1bGF0aW9ucz8NCj4gDQo+IEkgKnRoaW5rKiBJIHJlYWQgdGhpcyBhcyBDYXJsb3Mgc2F5aW5n 4oCmDQoNClNvcnJ5LCBJIGFjdHVhbGx5IG1lYW50IHRvIGFjdHVhbGx5IGtlZXAgZXhwYW5kaW5n IG9uIHRoaXMgcG9pbnQgYmV5b25kIHRoYXQgc2luZ2xlIHdvcmQsIGJ1dCBnb3QgZGlzdHJhY3Rl ZCBhbmQgaGl0IFNlbmQuDQoNClRoZXNlIGFyZSBlbmNhcHN1bGF0aW9ucyB3aGVyZSB3ZSBiZWxp ZXZlIElPQU0gaXMgYSB1c2VmdWwgbmF0dXJhbCBmaXQgYW5kIHdlIGhhdmUgaGVhcmQgdGhlIHBy b2JsZW0gdGhhdCBJT0FNIGFkZHJlc3NlcyBleGlzdHMgYW5kIHRoZXJl4oCZcyBhIGRlc2lyZSB0 byBzb2x2ZSBpdC4gQnV0IHRoYXQgc2FpZCwgdGhlcmXigJlzIG5vIHBhcnRpY3VsYXIgdW5kZXJs eWluZyBwYXR0ZXJuLCBub3IgcGVyaGFwcyBhbiBlYXN5IG5hbWUgdG8gZ3JvdXAgdGhvc2UuIA0K DQpUaGUgcmVsZXZhbnQgdGV4dCBzYXlzOg0KDQrigJxEYXRhLXJlY29yZHMgZm9yDQppbi1zaXR1 IE9BTSB3aWxsIG5lZWQgdG8gYmUgZW1iZWRkZWQgaW50byB0cmFuc3BvcnQgcHJvdG9jb2xzIHN1 Y2ggYXMNCklQdjQsIElQdjYsIFZYTEFOLUdQRSwgTElTUCwgTlNILCBTUnY2LCBHZW5ldmUu4oCd DQoNCldoZXJlIHRoZSBrZXkgaXMg4oCcc3VjaCBhcyINCg0KPiANCj4gV2Ugd2FudCB0byBkZWZp bmUgYSBsYXllci1pbmRlcGVuZGVudCwgZW5jYXBzdWxhdGlvbi1pbmRlcGVuZGVudCBnZW5lcmlj IGRhdGEgZm9ybWF0IGZvciBjYXJyeWluZyBhbnkgT0FNIGluZm9ybWF0aW9uIGluIHVzZXIgZGF0 YSBwYWNrZXRzLiBXZSBleHBlY3QgdGhpcyB0byBiZSB1c2VmdWwgaW4gdGhlIGZvbGxvd2luZyBs aXN0IG9mIGZvcndhcmRpbmcgZW5jYXBzdWxhdGlvbnMgPGluc2VydCBsaXN0PiBidXQgdGhlIGFj dHVhbCB1c2Ugb2YgYW5kIGVuY2Fwc3VsYXRpb24gb2YgdGhpcyBnZW5lcmljIGRhdGEgZm9ybWF0 IHdpbGwgYmUgd29ya2VkIG9uIGluIGNvb3JkaW5hdGlvbiB3aXRoIHRoZSB3b3JraW5nIGdyb3Vw cyByZXNwb25zaWJsZSBmb3IgdGhvc2UgZW5jYXBzdWxhdGlvbnMuDQo+IA0KPiBUaGlzLCB0byBt ZSwgc2VlbXMgc2ltaWxhciB0byB0aGUgYXBwcm9hY2ggdGFrZW4gYnkgdGhlIFNGQyB3b3JraW5n IGdyb3VwLiBUaGUgZ2VuZXJpYyBmb3JtYXQgaXMgYWdub3N0aWMgdG8gKGlnbm9yYW50IG9mPykg Ym90aCB0aGUgZW5jYXBzdWxhdGlvbiBhbmQgdGhlIHR5cGUgb2YgZGF0YSBjYXJyaWVkLg0KPiAN Cj4gSW4gYSBzZW5zZSwgb2YgY291cnNlLCBpdCBtZWFucyB0aGF0IGl0IGlzIHBvc3NpYmxlIHRo YXQgdGhlIGdlbmVyaWMgZGF0YSBmb3JtYXQgd2lsbCBiZSBpbnZlbnRlZCwgYnV0IG5ldmVyIHVz ZWQgKGJlY2F1c2Ugbm8gZ3JvdXAgcmVzcG9uc2libGUgZm9yIGEgZm9yd2FyZGluZyBlbmNhcHN1 bGF0aW9uIHRoaW5rcyBJT0FNIGlzIGFwcHJvcHJpYXRlIG9yIGRlc2lyYWJsZSkuIEFsdGhvdWdo IEkgc3VzcGVjdCB0aGF0IENhcmxvcyBhbmQgZnJhbmsgaGF2ZSBhbWJpdGlvbnMgaW4gdGhpcyBh cmVhIDotKQ0KPiANCj4gSSB3b3VsZCBjZXJ0YWlubHkgbGlrZSB0aGUgY2hhcnRlciB0byBiZSBt b3JlIGNsZWFyIGFib3V0IHdoYXQgaXMgYmVpbmcgYnVpbHQgKHRoZSBmaW5hbCBwYXJhZ3JhcGgg ZG9lcyBjb3ZlciBzb21lIG9mIHRoaXMsIGJ1dCB0aGUgZ2VuZXJpYyBuYXR1cmUgaXMgbm90IGFz IG9idmlvdXMgYXMgaXQgc2hvdWxkIGJlKS4NCj4gDQoNCkkgZG8gbm90IGRpc2FncmVlIHRoYXQg YSB0aWdodGVuaW5nIG9mIHRoZSBjaGFydGVyIHRleHQgaW4gdGhpcyByZWdhcmQgaXMgdXNlZnVs Lg0KDQpPbmUgYXBwcm9hY2ggaXMgdG8gbGlzdCBleHBsaWNpdGx5IHNvbWUgZW5jYXBzIHRoYXQg dGhlIGdyb3VwIHdvdWxkIGxvb2sgYXQgZmlyc3QsIGFuZCB0aGVuIGZvbGxvdyB3aXRoIG1vcmUg ZXhhbXBsZXMuDQoNCkFub3RoZXIgYXBwcm9hY2ggaXMgdG8gc2F5IOKAnHRoZSBncm91cCB3aWxs IGRlY2lkZSB3aGljaCBlbmNhcHMgdG8gd29yayBvbuKAnS4NCg0KRG8geW91IGhhdmUgdGhvdWdo dHMgb3IgcHJlZmVyZW5jZXMsIG9yIGFub3RoZXIgKGJldHRlcikgYXBwcm9hY2g/DQoNClRoYW5r cyENCg0KQ2FybG9zLg0KDQo+IEFkcmlhbg0KPiANCj4gDQoNCg== From nobody Fri Feb 10 07:17:20 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4061293EB; Fri, 10 Feb 2017 07:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 wOvDN4MpcP1n; Fri, 10 Feb 2017 07:17:10 -0800 (PST) Received: from TELEDG001RM001.telecomitalia.it (teledg001rm001.telecomitalia.it [217.169.121.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5461299A3; Fri, 10 Feb 2017 07:17:09 -0800 (PST) Received: from TELMBXB06RM001.telecomitalia.local (10.14.252.35) by TELEDG001RM001.telecomitalia.it (10.19.3.111) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 10 Feb 2017 16:17:07 +0100 Received: from TELMBXB02RM001.telecomitalia.local (10.14.252.27) by TELMBXB06RM001.telecomitalia.local (10.14.252.35) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 10 Feb 2017 16:17:06 +0100 Received: from TELMBXB02RM001.telecomitalia.local ([fe80::2845:411e:c732:e844]) by TELMBXB02RM001.telecomitalia.local ([fe80::2845:411e:c732:e844%20]) with mapi id 15.00.1263.000; Fri, 10 Feb 2017 16:17:06 +0100 From: Fioccola Giuseppe To: "Carlos Pignataro (cpignata)" , Stewart Bryant Thread-Topic: [Ioam] Internal WG Review: In-situ OAM (ioam) Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFf5E4AgAECTQCAAFm/gP//tUIAgAALP4CAAOsigIAAUJoAgAASibA= Date: Fri, 10 Feb 2017 15:17:06 +0000 Message-ID: References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <4f16e222-97e4-6f87-e1a3-79115db8f355@gmail.com> <05a1d761-aed9-f62f-920b-93ed587a9fd4@gmail.com> <4E3165FB-0EFE-4784-8E3F-91538DED6110@cisco.com> In-Reply-To: <4E3165FB-0EFE-4784-8E3F-91538DED6110@cisco.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.250] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Alvaro Retana \(aretana\)" , The IAB , "ioam@ietf.org" , "iesg@ietf.org" , Spencer Dawkins at IETF Subject: [Ioam] R: Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 15:17:14 -0000 SGkgQ2FybG9zLCBTdGV3YXJ0LCBBbGwNCmp1c3QgYW4gYWRkaXRpb24gb24gdGhpcyBwb2ludC4N Ck1hcmtpbmcgbWV0aG9kIGNvdWxkIGJlIGNvbnNpZGVyZWQgYm90aCBoeWJyaWQgYW5kIHBhc3Np dmUgZGVwZW5kaW5nIG9uIHRoZSBhcHBsaWNhdGlvbi4NCkkgYWdyZWUgdXBvbiBIeWJyaWQgVHlw ZSBJIFBNIGRlZmluaXRpb24gaW4gc29tZSBjYXNlcy4NCkJ1dCBpbiBvdGhlciBjYXNlcyBpdCBj b3VsZCBiZSBhbHNvIGRlZmluZWQgYXMgUGFzc2l2ZSBQTTogZm9yIGluc3RhbmNlIGEgdHJ1ZSBl eGFtcGxlIG9mIHBhc3NpdmUgYXBwbGljYXRpb24gaXMgaW4gZHJhZnQtaWV0Zi1iaWVyLXBtbW0t b2FtLTAxLCB3aGVyZSBtYXJraW5nIG1ldGhvZCBzaG91bGQgbm90IG1vZGlmeSB0aGUgYWN0dWFs IGRhdGEgcGFja2V0IHByb2Nlc3NpbmcgYmVoYXZpb3IsIGJ5IHVzaW5nIGEgZGVkaWNhdGVkIE9B TSBmaWVsZCBpbiBCSUVSIEhlYWRlci4NCg0KR2l1c2VwcGUNCg0KLS0tLS1NZXNzYWdnaW8gb3Jp Z2luYWxlLS0tLS0NCkRhOiBJb2FtIFttYWlsdG86aW9hbS1ib3VuY2VzQGlldGYub3JnXSBQZXIg Y29udG8gZGkgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQpJbnZpYXRvOiB2ZW5lcmTDrCAx MCBmZWJicmFpbyAyMDE3IDE1OjIxDQpBOiBTdGV3YXJ0IEJyeWFudA0KQ2M6IGllc2dAaWV0Zi5v cmc7IEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpOyBUaGUgSUFCOyBTcGVuY2VyIERhd2tpbnMgYXQg SUVURjsgaW9hbUBpZXRmLm9yZw0KT2dnZXR0bzogUmU6IFtJb2FtXSBJbnRlcm5hbCBXRyBSZXZp ZXc6IEluLXNpdHUgT0FNIChpb2FtKQ0KDQpIaSwgU3Rld2FydCwNCg0KDQo+IE9uIEZlYiAxMCwg MjAxNywgYXQgNDozMiBBTSwgU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNv bT4gd3JvdGU6DQo+DQo+DQo+DQo+IE9uIDA5LzAyLzIwMTcgMTk6MzAsIENhcmxvcyBQaWduYXRh cm8gKGNwaWduYXRhKSB3cm90ZToNCj4+IEhpLCBTdGV3YXJ0LA0KPj4NCj4+IE1hbnkgdGhhbmtz IGZvciB0aGUgY29tbWVudHMsIHBsZWFzZSBzZWUgaW5saW5lLg0KPj4NCj4+PiBPbiBGZWIgOSwg MjAxNywgYXQgMTo1MCBQTSwgU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNv bT4gd3JvdGU6DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gT24gMDkvMDIvMjAxNyAxNzoxOCwgQ2FybG9z IFBpZ25hdGFybyAoY3BpZ25hdGEpIHdyb3RlOg0KPj4+PiBQYXNzaXZlIG1lYW5zIOKAmHNvbGVs eSBieSBvYnNlcnZhdGlvbiBhbmQgd2l0aG91dCBtb2RpZmljYXRpb24gdG8gdGhlIHBhY2tldOKA mSAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1hY3RpdmUtcGFz c2l2ZS0wNiNzZWN0aW9uLTMuNikuDQo+Pj4gQ2FybG9zLCB0aGF0IGlzIG5vdCBxdWl0IHdoZXJl IHdlIGFyZSBnb2luZyB3aXRoIHBhc3NpdmUuIFdlIHVzZSBwYWNrZXQgbWFya2luZyB0byBiYXRj aCB0aGUgcGFja2V0cyBmb3IgbG9zcyBtZWFzdXJlbWVudCwgYW5kIHdlIGFyZSBwbGFubmluZyB0 byB0cmlnZ2VyIGRlbGF5L2ppdHRlciBtZWFzdXJlbWVudCB0aHJvdWdoIG1hcmtpbmcuDQo+Pj4N Cj4+IEnigJlsbCBmb2xsb3cgZG93biB0aGlzIHRhbmdlbnQgZm9yIGEgYml0Lg0KPj4NCj4+IEkg dW5kZXJzdGFuZCBhbmQgYXMgeW91IGtub3cgSeKAmW0gd2VsbCBhd2FyZSBvZiB0aGUgKGFsdGVy bmF0ZSkgcGFja2V0IG1hcmtpbmcgdGVjaG5pcXVlcyBhbmQgZGlmZmVyZW50IG1ldGhvZHMuDQo+ Pg0KPj4gSG93ZXZlciwgdGhlICpjdXJyZW50KiBkZWZpbml0aW9uIGlzIHF1aXRlIHVuYW1iaWd1 b3VzOg0KPj4NCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3Nzk5I3NlY3Rpb24t My42DQo+PiDigJwNCj4+IDMuNi4gIFBhc3NpdmUgTWV0aG9kcw0KPj4NCj4+ICAgIFBhc3NpdmUg TWV0aG9kcyBvZiBNZWFzdXJlbWVudCBhcmU6DQo+Pg0KPj4gICAgbyAgYmFzZWQgc29sZWx5IG9u IG9ic2VydmF0aW9ucyBvZiBhbiB1bmRpc3R1cmJlZCBhbmQgdW5tb2RpZmllZA0KPj4gICAgICAg cGFja2V0IHN0cmVhbSBvZiBpbnRlcmVzdCAoaW4gb3RoZXIgd29yZHMsIHRoZSBtZXRob2Qgb2YN Cj4+ICAgICAgIG1lYXN1cmVtZW50IE1VU1QgTk9UIGFkZCwgY2hhbmdlLCBvciByZW1vdmUgcGFj a2V0cyBvciBmaWVsZHMgb3INCj4+ICAgICAgIGNoYW5nZSBmaWVsZCB2YWx1ZXMgYW55d2hlcmUg YWxvbmcgdGhlIHBhdGgpLg0KPj4g4oCcDQo+Pg0KPj4gU2luY2UgYm90aCB0aG9zZSBkYXRhcG9p bnRzIGFyZSByb290ZWQgaW4gSVBQTSwgSeKAmWQgc3VnZ2VzdCB3b3JraW5nIHRocm91Z2ggdGhl IGRlZmluaXRpb25zIG9uIElQUE0gYW5kIGhvdyBtYXJraW5nIGZpdHMgKHNpbmNlIGl0IGlzIG5v dCBvbmx5IG9uIG9ic2VydmF0aW9uIHBvaW50cykNCj4+DQo+PiBOb3csIGJyaW5naW5nIHRoaXMg YmFjayB0byB0aGUgcmVsZXZhbmNlIG9mIHRoZSBJbi1zaXR1IE9BTSAoaW9hbSkgY2hhcnRlciwg bXkgb25seSBwb2ludCBpcyB0aGF0IEluLXNpdHUgT0FNIGlzIG5laXRoZXIgcGFzc2l2ZSBub3Ig YWN0aXZlLg0KPg0KPiAuLi4gYW5kIHRoZSBwb2ludCBJIG1ha2UgaXMgdGhhdCBwYWNrZXQgbWFy a2luZyAod2hpY2ggSSB0aGluayB3ZSBoYXZlIGVzdGFibGlzaGVkIGlzIHRoZSBvbmx5IHZpYWJs ZSB3YXkgb2YgbWFraW5nIGFjY3VyYXRlIGxvc3MgbWVhc3VyZW1lbnRzIGluIGNvbm5lY3Rpb25s ZXNzIG5ldHdvcmtpbmcpIGlzIGFsc28gbmVpdGhlciBhY3RpdmUgb2YgcGFzc2l2ZSBhY2NvcmRp bmcgdG8gdGhlc2UgZGVmaW5pdGlvbnMuDQoNClRoYXQgaXMgY29ycmVjdCwgaXQgaXMgSHlicmlk IFR5cGUgSS4gU29ycnkgaWYgSSBtaXN1bmRlcnN0b29kIHdoZW4geW91IHNhaWQg4oCcIENhcmxv cywgdGhhdCBpcyBub3QgcXVpdCB3aGVyZSB3ZSBhcmUgZ29pbmcgd2l0aCBwYXNzaXZlLiBXZSB1 c2UgcGFja2V0IG1hcmtpbmcgW+KApl3igJ0uDQoNCkJ1dCBpbiBhbnkgY2FzZSwgSSBkbyBub3Qg YmVsaWV2ZSB0aGUgZHJhZnQgY2hhcnRlciBjbGFpbXMgdG8gZG8gbWFya2luZyAobW9yZSBvbiB0 aGlzIGJlbG93IHRob3VnaCkuDQoNCkkgd29uZGVyLCBhcyBhbiBhc2lkZSwgaWYgdGhlcmXigJlz IGFueSB0YWtlLWF3YXkgZm9yIGRyYWZ0LWlldGYtaXBwbS1hbHQtbWFyay0wM+KAmXMgdGl0bGUg 4oCcQWx0ZXJuYXRlIE1hcmtpbmcgbWV0aG9kIGZvciBwYXNzaXZlIHBlcmZvcm1hbmNlIG1vbml0 b3JpbmfigJ0uDQoNCj4NCj4+DQo+Pj4gQXMgeW91IGtub3cgbWFya2luZyBpcyBtdWNoIGVhc2ll ciBpbiBNUExTIHRoYXQgSVAuDQo+Pj4NCj4+PiBJIHRoaW5rIHRoZSBrZXkgZGlzdGluZ3Vpc2hl ciBpcyByZWFsbHkgdGhhdCBpbi1zaXR1IGlzIGFib3V0IGVtYmVkZGluZyBPQU0gbWV0YS1kYXRh IGluIHVzZXIgZGF0YSB0cmFmZmljLg0KPj4gVGhpcyBpcyBhIGdvb2QgcG9pbnQuDQo+Pg0KPj4g SSBhZ3JlZS4NCj4+DQo+PiBJIGJlbGlldmUgdGhpcyBpcyBhbHJlYWR5IGNsZWFyIGluIHRoZSBj aGFydGVyLCBhbGwgdGhlIHdheSBmcm9tIHRoZSB2ZXJ5IGZpcnN0IHNlbnRlbmNlOg0KPj4NCj4+ IOKAnCBJdCBpcyBiYXNlZCBvbiB0ZWxlbWV0cnkgaW5mb3JtYXRpb24gd2hpY2ggaXMgZW1iZWRk ZWQgd2l0aGluIGxpdmUgZGF0YSBwYWNrZXRzLuKAnQ0KPj4NCj4+IERvIHlvdSBiZWxpZXZlIHRo aXMgaXMgbm90IGNsZWFyIGluIHRoZSBjaGFydGVyPyBEbyB5b3UgaGF2ZSBzcGVjaWZpYyBzdWdn ZXN0aW9ucyBvciBjb25jcmV0ZSByZWNvbW1lbmRhdGlvbnMgdGhhdCBjYW4gaW1wcm92ZSB0aGUg Y2hhcnRlciB0ZXh0Pw0KPg0KPiBJIHN1cHBvc2UgeW91IGNvdWxkIHNheTogSXQgaXMgYmFzZWQg b24gdGVsZW1ldHJ5IGluZm9ybWF0aW9uIHdoaWNoIGlzIGVtYmVkZGVkIHdpdGhpbiBsaXZlIGRh dGEgcGFja2V0cyBhbmQgaXMgZGlzdGluY3QgZnJvbSBwYWNrZXQgcGFya2luZyBtZXRob2RzIGJl aW5nIGRldmVsb3BlZCBlbHNld2hlcmUgaW4gdGhlIElFVEYuDQo+DQoNClRoYXTigJlzIG9uZSBw b3RlbnRpYWwgYXBwcm9hY2guIFRvIG1lLCB0aG91Z2gsIOKAnGVtYmVkZGVkIHdpdGhpbiBsaXZl IGRhdGEgcGFja2V0c+KAnSBpcyBkaWZmZXJlbnQgZnJvbSDigJxtYXJraW5nIHBhY2tldHPigJ07 IHRoYXQgc2FpZCwgSSBkbyBub3Qgc2VlIGhvdyBpdCBjYW4gaHVydC4NCg0KVGhlcmUgaXMgb25l IGFkZGl0aW9uYWwgd3JpbmtsZSB0aG91Z2g6IElPQU0gaXMgbm90IGxpbWl0ZWQgdG8gUGVyZm9y bWFuY2UgTWFuYWdlbWVudCAoUE0pLCBidXQgbW9yZSBnZW5lcmFsbHkgaW5jbHVkZXMgdGhpbmdz IGxpa2UgcGF0aCB0cmFjaW5nLiBTbyBwZXJoYXBzIGFkZGluZyB0aGUgdGV4dCBhYm92ZSBtaWdo dCBjYXVzZSBjb25mdXNpb25zLg0KDQo+IEkgaGF2ZSBub3QgdGhvdWdodCBpdCB0aHJvdWdoLCBi dXQgSSBhbSB3b25kZXJpbmcgd2hhdCBkaXN0aW5ndWlzaGVzIHRoZSBwYWNrZXQgdHlwZXMgeW91 IGxpc3QgKElQdjQsIElQdjYsIFZYTEFOLUdQRSwgTElTUCwgTlNILCBTUnY2LCBHZW5ldmUpIGZy b20gb3RoZXIgcGFja2V0IHR5cGVzLCB0aGUgb2J2aW91cyBvbmUgYmVpbmcgTVBMUy4gTm90IHRo YXQgSSBhbSBhdCBhbGwga2VlbiBvbiB0cnlpbmcgdG8gZ2V0IHRoaXMgaW50byB0aGUgc2ltcGxl IGZhc3QgZm9yd2FyZGVycyB3ZSB1c2UgZm9yIE1QTFMuIEluIG90aGVyIHdvcmRzIHdoYXQgaXMg dGhlIGdlbmVyaWMgY2xhc3Mgb2YgcGFja2V0cyB5b3UgYXJlIHRhcmdldHRpbmc/DQo+DQoNCkVu Y2Fwc3VsYXRpb25zPw0KDQpUaGFua3MhDQoNCuKAlCBDYXJsb3MuDQoNCj4gU3Rld2FydA0KPg0K Pj4NCj4+IFRoYW5rcyENCj4+DQo+Pj4gLSBTdGV3YXJ0DQo+Pg0KPj4g4oCUDQo+PiBDYXJsb3Mg UGlnbmF0YXJvLCBjYXJsb3NAY2lzY28uY29tDQo+Pg0KPj4g4oCcU29tZXRpbWVzIEkgdXNlIGJp ZyB3b3JkcyB0aGF0IEkgZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1ha2UgbXlzZWxmIHNv dW5kIG1vcmUgcGhvdG9zeW50aGVzaXMuIg0KPj4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCklvYW0gbWFpbGluZyBsaXN0DQpJb2FtQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lvYW0NCg0KUXVlc3Rv IG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1l bnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lh c2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZv cm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNl dnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdh dGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92 dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWlu YXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRo b3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRl ciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQoNCg== From nobody Fri Feb 10 07:20:07 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362D712998A; Fri, 10 Feb 2017 07:20:02 -0800 (PST) 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 2b1F1rXX-WkU; Fri, 10 Feb 2017 07:20:00 -0800 (PST) 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 98F131299A3; Fri, 10 Feb 2017 07:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3860; q=dns/txt; s=iport; t=1486739999; x=1487949599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=u1qhT78fiDX14jnYZJ1LSgs63jmQdc+SAYcIEBQ6qnI=; b=dWf8OPGrNzBRImv5zrKEn6E8EJBQ6MGTg7VvVWWQvXI4c66vFlvJfeXz crDCzhsqon9rlSpdUIJ48PDezzDM5BB2tEo67Z2ljzFpHZ6vr4vBedb0y RY5O2SciMGCt6l3PJQ9J1QzYecApdoqrzMvntbCLo1xhuAPfozDAXQN7l g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AwDR2J1Y/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1KBageDUpwUlTaCDYYiAhqCX0EWAQIBAQEBAQEBYiiEaQEBAQM?= =?us-ascii?q?BIxEzEgULAgEIGAICJgICAjAVEAIEDgWJcAiwA4Ili1ABAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgQuFQYIFgmqHWi6CMQWVVIYeAYoOiAWRBZMUASYHKn5PFU0BhjB?= =?us-ascii?q?1iRKBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,142,1484006400"; d="scan'208";a="384042641" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2017 15:19:58 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v1AFJw9A009340 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 15:19:58 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Feb 2017 10:19:57 -0500 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; Fri, 10 Feb 2017 10:19:56 -0500 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel Thread-Topic: [Ioam] Internal WG Review: In-situ OAM (ioam) Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFhgq0A///ULoCAAVKhgIAAAhIAgAAGFoA= Date: Fri, 10 Feb 2017 15:19:56 +0000 Message-ID: <245E4E88-DBE4-49E5-A05E-EB46C0BF2928@cisco.com> References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <87206d4b-9b2c-f44c-754c-628e8c8e8887@cs.tcd.ie> <30D731F6-7073-486B-9395-BF1FC31F004C@cisco.com> <0be201d283ae$1b120680$51361380$@olddog.co.uk> In-Reply-To: <0be201d283ae$1b120680$51361380$@olddog.co.uk> 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.48.110] Content-Type: text/plain; charset="utf-8" Content-ID: <136163A5E5D6304DACC2E146CFBA0D6D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Alvaro Retana \(aretana\)" , "ioam@ietf.org" , The IESG , The IAB , Stephen Farrell Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 15:20:02 -0000 DQo+IE9uIEZlYiAxMCwgMjAxNywgYXQgOTo1OCBBTSwgQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9s ZGRvZy5jby51az4gd3JvdGU6DQo+IA0KPj4+PiAxKSBJJ20gc3VyZSB0aGVyZSBhcmUgZ29vZCB0 aGluZ3Mgb25lIGNhbiBkbyB3aXRoIHN1Y2gNCj4+Pj4gbWFya2luZywgYnV0IGl0IGlzIHZlcnkg dW5jbGVhciB0byBtZSBob3cgdGhpcyBwcm9wb3NhbA0KPj4+PiBkb2Vzbid0IGFsc28gZmFsbCBh Zm91bCBvZiBhbGwgdGhlIHByaXZhY3kgZG93bnNpZGVzIG9mDQo+Pj4+IHRoZSBTUFVEL1BMVVMg cHJvcG9zYWwuIE15IHVuZGVyc3RhbmRpbmcgb2YgdGhvc2UgcHJpdmFjeQ0KPj4+PiBkb3duc2lk ZXMgd2FzIHRoYXQgYW55IGdlbmVyaWMvZXh0ZW5zaWJsZSBtYXJraW5nIHNjaGVtZQ0KPj4+PiAo d2hldGhlciBvZiBwYWNrZXRzIG9yIHRyYW5zcG9ydCBjb25uZWN0aW9ucy9mbG93cykgY291bGQN Cj4+Pj4gZWFzaWx5IGJlIGFidXNlZCBpbiBtYW55IHByaXZhY3kgdW5mcmllbmRseSB3YXlzLiBO b3RlDQo+Pj4+IHRoYXQgSSdtIG5vdCBjbGFpbWluZyB0aGVyZSBpcyBJRVRGIGNvbnNlbnN1cyBv biB0aGF0DQo+Pj4+IGJ1dCBJIGRvIGNsYWltIGl0IHdhcyBhIHNpZ25pZmljYW50IGlzc3VlIGZv ciBTUFVEL1BMVVMNCj4+Pj4gYW5kIHdvdWxkIGxpa2UgdG8ga25vdyB3aHkgKGFuZCBob3BlKSBp dCBpcyBub3QgYW4gaXNzdWUNCj4+Pj4gaGVyZS4gQ2FuIHNvbWVvbmUgaGVscCBtZSB1bmRlcnN0 YW5kIHdoYXQncyBkaWZmZXJlbnQgaGVyZQ0KPj4+PiBzbyB3ZSBhdm9pZCB0aGF0IHNhbWUga2lu ZCBvZiBtZWdhLWRlYmF0ZT8NCj4+IA0KPj4gTm90ZSB0aGF0IHRoaXMgcHJvcG9zYWwgY29uY2Vy bnMgaXRzZWxmIHdpdGggT0FNIGluZm9ybWF0aW9uLCBhbmQgbm90IGFzIGENCj4+IGdlbmVyaWMg Y29udGFpbmVyIGZvciBhbGwtdGhpbmdzLiBJdCBpcyBub3QgZm9yIGFwcGxpY2F0aW9uIGluZm9y bWF0aW9uLg0KPiANCj4gSG1tbS4NCj4gT25jZSB5b3UgZGVmaW5lIGEgY2hhbm5lbCB0byBjYXJy eSBvdGhlciBzdHVmZiBhbG9uZyB3aXRoIGRhdGEgcGFja2V0cyBpdCB3aWxsIGJlIHVzZWQgZm9y IHB1cnBvc2VzIGFzIHlldCB1bmRyZWFtZWQgb2YuDQoNCkkgdW5kZXJzdGFuZCB0aGF0IOKAlCB3 aGljaCBpcyB0cnVlIHByZXR0eSBtdWNoIGZvciBhbnkgbmV3IHByb3RvY29sIGZpZWxkLg0KDQpJ IHdhcyBjdXJpb3VzIHRvIHNlZSBpZiB0aGVyZSB3ZXJlIG1vcmUgc3BlY2lmaWNzIG9uIHRoZSBQ TFVTIGRpc2N1c3Npb24gYmV5b25kIHRoaXMgdGhhdCBwYXJ0aWN1bGFybHkgYXBwbHkgdG8gSU9B TS4NCg0KPiANCj4gVG8gZ2l2ZSB5b3UgYSBoaW50Li4uDQo+IA0KPiBUaGUgU0ZDJ3MgTlNIIGNh biBjYXJyeSBtZXRhZGF0YSBhbG9uZyB3aXRoIGRhdGEgcGFja2V0cyBpbiBvcmRlciB0aGF0IHNl cnZpY2UgZnVuY3Rpb25zIGNhbiBjb29yZGluYXRlIHRoZWlyIGFjdGlvbnMgYW5kIHJlY2VpdmUg aGludHMgZnJvbSBwYWNrZXQgY2xhc3NpZmllcnMuDQo+IA0KPiBBIHJlY2VudCBxdWVzdGlvbiB3 YXMuLi4NCj4gU3VwcG9zZSBhbiBhcHBsaWNhdGlvbiB0aGF0IHMgc291cmNpbmcgcGFja2V0cyB3 aXNoZXMgdG8gY29tbXVuaWNhdGUgd2l0aCBhbiBhcHBsaWNhdGlvbiByZWNlaXZpbmcgdGhvc2Ug cGFja2V0cyBpbiBvcmRlciB0byBleHBsYWluIGhvdyB0aGUgcGFja2V0cyBzaG91bGQgYmUgdHJl YXRlZC4gQ291bGQgaXQgdXNlIHRoZSBOU0ggYW5kIHB1dCBpbmZvcm1hdGlvbiBpbiB0aGUgbWV0 YWRhdGEgZXZlbiB0aG91Z2ggdGhlcmUgaXMgbm8gc2VydmljZSBmdW5jdGlvbiBjaGFpbiBpbnZv bHZlZCBhbmQgbm8gc2VydmljZSBmdW5jdGlvbnMgb24gdGhlIHBhdGg/DQoNClJpZ2h0LiBUaGlz IGV4YW1wbGUgZGVwaWN0cyBhIHVzZSBiZXlvbmQgdGhlIG9yaWdpbmFsIGdvYWwuIENvdWxkIGFu eSBJUCBvcHRpb24gYmUgdXNlZCB0byBjYXJyeSBvdGhlciBkYXRhPyANCg0KSW4gdGhlIE5TSCBl eGFtcGxlLCB0aGUgcXVlc3Rpb24gaXMgYWJvdXQgdXNpbmcgYW4gU0ZDIG1ldGFkYXRhIGNoYW5u ZWwgYXMgYW4gaW50ZXItU0Ygc2lnbmFsaW5nIChjb25maWd1cmF0aW9uPykgY2hhbm5lbCwgYW5k IGFwcGxpY2F0aW9uLXRvLWFwcGxpY2F0aW9uIGNvbW11bmljYXRpb24gY2hhbm5lbC4gSSBoYXZl IHRob3VnaHRzIGFib3V0IHRoaXMsIHN0YXJ0aW5nIGZyb20gdGhlIGZhY3QgdGhhdCBpZiB0aGVy ZSBpcyBubyBTRlAgdGhlcmUgaXMgbm8gZGF0YSwgYW5kIGlmIHRoZXJl4oCZcyBubyBkYXRhIHRo ZXJl4oCZcyBubyBtZXRhZGF0YSwgYW5kIHRoZSBtZXRhZGF0YSBmaWVsZCBjYXJyaWVzLCB3ZWxs LCBtZXRhZGF0YS4gQnV0IHBvc2luZyB0aGUgcXVlc3Rpb24gZG9lcyBub3QgcmVuZGVyIHRoZSBO U0ggYXMgbm90IHVzZWZ1bCBmb3IgY2FycnlpbmcgU0ZQIGNvbnRleHR1YWwgZGF0YS4NCg0KRm9y IElPQU0sIHRoZSBkYXRhIHRvIGJlIGNhcnJpZWQgaXMgd2VsbCBzcGVjaWZpZWQgT0FNIGRhdGEu IA0KDQo+IA0KPiBTbywgaWYgeW91IG9wZW4gYSBjaGFubmVsLCBpdCB3aWxsIGJlIHVzZWQuDQo+ IFdpbGwgaXQgYWxzbyBwcm92aWRlIGEgY292ZXJ0IGNoYW5uZWw/IFdobyBjYW4gc2F5Pw0KPiAN Cg0KQSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIHdvdWxkIG5lZWQgdG8gYWRkcmVzcyB0aGVzZSBz ZWN1cml0eSBhbmQgcHJpdmFjeSBjb25zaWRlcmF0aW9ucy4gV2hpY2ggcGFydCBvZiB0aGlzIG91 Z2h0IHRvIGJlIGNvZGlmaWVkIGluIHRoZSBjaGFydGVyPw0KDQpUaGFua3MhDQoNCuKAlCBDYXJs b3MuDQoNCj4gQWRyaWFuDQo+IA0KPiANCg0K From nobody Fri Feb 10 07:32:42 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB5B1299C8 for ; Fri, 10 Feb 2017 07:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 q_dVbaQVCIk5 for ; Fri, 10 Feb 2017 07:11:47 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4F31299C9 for ; Fri, 10 Feb 2017 07:11:47 -0800 (PST) Received: (qmail 32562 invoked from network); 10 Feb 2017 16:11:45 +0100 Received: from p5dec2a07.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.42.7) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 10 Feb 2017 16:11:45 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <0bdcfd0be2c84ffa81b1658af60f084d@XCH-RCD-008.cisco.com> Date: Fri, 10 Feb 2017 16:11:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9826D9EC-E161-48A6-AC5B-EA0C73BFE526@kuehlewind.net> References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> <0bdcfd0be2c84ffa81b1658af60f084d@XCH-RCD-008.cisco.com> To: "Frank Brockners (fbrockne)" X-Mailer: Apple Mail (2.3259) Archived-At: X-Mailman-Approved-At: Fri, 10 Feb 2017 07:32:41 -0800 Cc: "Carlos Pignataro \(cpignata\)" , The IAB , "iesg@ietf.org" , "ioam@ietf.org" , "Alvaro Retana \(aretana\)" , Spencer Dawkins at IETF Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 15:11:50 -0000 Hi Frank, hi all, please see in-line. > Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne) = : >=20 > Hi Mirja, >=20 > you raise an interesting point. The IPPM charter states " Specifying = network or lower layer OAM mechanisms is out of scope of the IPPM = charter.", whereas the WG has " Submit a draft on the IPv6 Performance = and Diagnostic Metrics (PDM) Destination Option as Proposed Standard=20 > draft-ietf-ippm-6man-pdm-option" as a milestone. I'd assume that we'd = likely qualify IPv6 as a transport protocol=E2=80=A6=20 If you also cite the sentence before this, this might become clearer: "The IP Performance Metrics (IPPM) Working Group develops and maintains standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services and applications running over transport layer protocols (e.g. TCP, UDP) over IP. Specifying = network or lower layer OAM mechanisms is out of scope of the IPPM charter.=E2=80=9C= It=E2=80=99s focused on performance measurements of data delivery = services and application, not metric sthat are specific to network = operation e.g. up-time of a router (as an example that just came to my = mind). So to me the scope and the goals of IPPM and IOAM are overlapping = currently as for me "real-time telemetry of individual data packets and = flows=E2=80=9C is exactly what IPPM is doing. >=20 > So far I understood the main focus of the new IOAM WG to be = network-layer focused, i.e. piggyback OAM-meta-data onto network-layer = protocols - but that does not necessarily need to be always the case as = you implicitly highlight by drawing the link to IPPM. One could also do = so using e.g. TCP options. I did not read the statement on IPPM in the = draft charter as "not cooperating with IPPM" - I read it in a way that = methods that do not piggyback information on live traffic are not = considered in IOAM. That said, especially when it comes to export and = interpretation of in-situ OAM data, there might indeed be common ground = between IOAM and IPPM. My point is not that there needs to be cooperation. My point is that we = already have a working group that is mostly charter to do what you want = to do. Mirja >=20 > How about we add another sentence to the charter that underlines the = fact that IOAM would actively seek cooperation with other related = efforts? We could add something like:=20 >=20 > "The IOAM WG seeks cooperation with other appropriate standards bodies = and forums to promote consistent approaches, as well as definition and = interpretation of in-situ OAM data." >=20 > This would naturally capture IETF WGs like IPPM - but also efforts = like INT in P4, hence we'd even cast the net a little wider. >=20 > Thoughts? >=20 > Thanks, Frank >=20 > -----Original Message----- > From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind (IETF) > Sent: Freitag, 10. Februar 2017 13:10 > To: Carlos Pignataro (cpignata) ; Alvaro Retana = (aretana) > Cc: iesg@ietf.org; The IAB ; Spencer Dawkins at IETF = ; ioam@ietf.org > Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) >=20 > Hi all, >=20 > also one more comment on this point: >=20 >> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata) = : >>=20 >>>> Is there any connection with IPPM? >>=20 >> Yes, there is, as already mentioned above. >=20 >=20 > The charter currently says: >=20 > "Other ongoing OAM-related efforts in working groups(s) such as MPLS = and IPPM that do not piggyback information onto the live user data = traffic are out of scope of the IOAM WG.=E2=80=9C >=20 > which indictates that cooperation with IPPM is not planned. >=20 > To me in general the relation between this work and other ongoing work = in the IETF is not very clear and IPPM has several documents and = milestones that are in scope for this work: >=20 > - Submit a draft on the IPv6 Performance and Diagnostic Metrics (PDM) = Destination Option as Proposed Standard: draft-ietf-ippm-6man-pdm-option = (this draft is mainly done and silenter the publication process soon to = my understanding) >=20 > - Submit an Experimental draft on coloring-based hybrid measurement = methodologies for loss and delay to the IESG: = draft-ietf-ippm-alt-mark-03 >=20 > I don=E2=80=99t think that the assessment in the charter that IPPM's = scope does not include piggybacked information is correct. Looking at = draft-brockners-inband-oam-transport-02, I think that any work on IPV6 = and IPv6 in this scope should be done in IPPM because that=E2=80=99s = were this work is already on-going and where the measurement expertise = is. >=20 > Mirja >=20 >=20 >=20 >=20 > _______________________________________________ > Ioam mailing list > Ioam@ietf.org > https://www.ietf.org/mailman/listinfo/ioam From nobody Fri Feb 10 09:06:01 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F59129A42; Fri, 10 Feb 2017 08:59:41 -0800 (PST) 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 z2rq7o26uIBs; Fri, 10 Feb 2017 08:59:39 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 3CA8C129A45; Fri, 10 Feb 2017 08:59:38 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id l19so24483963ywc.2; Fri, 10 Feb 2017 08:59:38 -0800 (PST) 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=RyE5W0uGbb5RGqEROIrlNrmJtqlaTYHBlxXt7PNS1sQ=; b=lEyXGBYAvuVLvb9/G+96zYO+Y3ZraVos8lu4iMzizmqwlXYz7PE/Y4XvGd48nJPi3F sAfOR+usNbz/sS9hYrWjh9Wnlmn9n3d5tWaqlIfVvM2nLVqRdRPrJ85tVA7Jl8sYdS2B hRu6zTixLpfcX/riIupOVwbQ7YKgH0mZDRqk0gvJggi5A6gYxky4Poi1+MfJX2rVodEL gDps0GZK3/pgcOCARdzyCv5O5R9EY0NZtiAusE5CEjqol9e+q3KS8naKFNpITx2+E0BC /nfd0tJz55OS/v7pN5omJTOhqa+2QIMTwUzI77UaaZghHUCUsMDfbOaeueCCcWuaXeUH akzw== 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=RyE5W0uGbb5RGqEROIrlNrmJtqlaTYHBlxXt7PNS1sQ=; b=OIdvul4JqQUa3ul5WrcabsQJw4QnC8vtMNJsjHAgJ5MenhA8pV2lavqIml7k2WDSbj fmxv7bxYIilj9Mhmd7dMffG+LXbJ2dfsHLuJu05Lx9oLqPkuCB2s+OLwcgRs83aOj1Yi HuZWsAE9C6gx3kRuJGN0xwtOtz7gBpBFEBnTjuzslWbz48yKFoe0IIP35PjPzWtRSeI+ EWVkAA0f5UCY55Em3xW4vH7C/3VlVT98+POJQcda+W0qQjQ74SopuXfpux73oUdzkL+R sLG4fdDXwqyKl31c3elwqlm20ohjiZ0AIscYF1nAY8V3+TNq3KX2C/3coheD2Q8xd8eX 9n8A== X-Gm-Message-State: AMke39m7SaPH0FI6EBm5zxyuuAJSQkj8SE4BHdQ1S1BLsBskSCSzG519X06sdZHUCMjTtUdErKVYZ6btsFBP2A== X-Received: by 10.13.204.18 with SMTP id o18mr7047910ywd.347.1486745977167; Fri, 10 Feb 2017 08:59:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.234.9 with HTTP; Fri, 10 Feb 2017 08:59:36 -0800 (PST) Received: by 10.37.234.9 with HTTP; Fri, 10 Feb 2017 08:59:36 -0800 (PST) In-Reply-To: <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> From: Spencer Dawkins at IETF Date: Fri, 10 Feb 2017 10:59:36 -0600 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a114edf24d728b5054830056c Archived-At: X-Mailman-Approved-At: Fri, 10 Feb 2017 09:06:00 -0800 Cc: "Alvaro Retana \(aretana\)" , iab@iab.org, "iesg@ietf.org" , "ioam@ietf.org" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:59:42 -0000 --001a114edf24d728b5054830056c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've read through this thread to the bottom as of the time I'm sending this note, but just to wrap up my own questions ... On Feb 9, 2017 11:18, "Carlos Pignataro (cpignata)" wrote: Thanks, Alvaro. Hi, Spencer, Please find some follow-ups inline. Look forward to understanding if they clarify, or what specific suggestions can make the charter text better. =E2=80=94 Carlos Pignataro, carlos@cisco.com =E2=80=9CSometimes I use big words that I do not fully understand, to make = myself sound more photosynthesis." > On Feb 9, 2017, at 10:57 AM, Alvaro Retana (aretana) wrote: > > Spencer: > > Hi! I=E2=80=99m cc=E2=80=99ing the list to get feedback from them. > > Thanks for your comments! > > Alvaro. > >> On 2/8/17, 2:32 PM, "iesg on behalf of Spencer Dawkins at IETF" < iesg-bounces@ietf.org on behalf ofspencerdawkins.ietf@gmail.com> wrote: >> >> So, thinking about this some more ... >> >> Most of what follows is questions, so you may be educating me in most of the cases, instead of changing text in the proposed charter. >> >> On Wed, Feb 8, 2017 at 12:32 PM, IETF Secretariat < ietf-secretariat-reply@ietf.org> wrote: >>> >>> >>> A new IETF WG is being considered in the IETF. The draft charter for this >>> WG is provided below for your review and comment. >>> >>> Review time is one week. >>> >>> The IETF Secretariat >>> >>> In-situ OAM (ioam) >>> ----------------------------------------------------------------------- >>> Current status: Proposed WG >>> >>> Chairs: >>> TBD >>> >>> Assigned Area Director: >>> Alvaro Retana >>> >>> Routing Area Directors: >>> Alia Atlas >>> Alvaro Retana >>> Deborah Brungard >>> >>> Mailing list: >>> Address: ioam@ietf.org >>> To subscribe: https://www.ietf.org/mailman/listinfo/ioam >>> Archive: https://mailarchive.ietf.org/arch/browse/ioam/ >>> >>> Charter: https://datatracker.ietf.org/doc/charter-ietf-ioam/ >>> >>> In-situ OAM provides real-time telemetry of individual data packets and >>> flows. >> >> Is it true to say that In-situ OAM provides real-time telemetry of individual data packets and flows, based on information embedded within live data packets? >> In-situ OAM records telemetry information by embedding it into actual data packets (as opposed to synthetic probes). In that context, I=E2=80=99d say = it is true =E2=80=94 however, see below. The clearest term I've seen pop up in this thread is "user data packets". I'd suggest that you consider adopting that term. >> I'm reading the current text as saying that this can do OAM for an individual packet. I don't even know what that means. >> >> I'm not quite sure I understand what a "live" data packet is. Is the point that this isn't injecting measurement traffic (so, "passive", rather than "active" - or is the text calling that "active probing")? But I'm guessing. >> Perhaps =E2=80=9Clive=E2=80=9D is the distractor here. I do wonder if =E2= =80=9Cactual=E2=80=9D might make it clearer. The challenge is that In-situ OAM is neither =E2=80=9Cactive=E2=80=9D not = =E2=80=9Cpassive=E2=80=9D measurement. Passive means =E2=80=98solely by observation and without modification to th= e packet=E2=80=99 (https://tools.ietf.org/html/draft-ietf-ippm-active- passive-06#section-3.6). Active means =E2=80=98generating (accompanying / synthetic) packet streams= =E2=80=99 ( https://tools.ietf.org/html/draft-ietf-ippm-active-passive-06#section-3.4). Thus, In-situ OAM is its own class. Based on this, do you have another recommendation? Does =E2=80=9Cactual=E2= =80=9D instead of =E2=80=9Cactive=E2=80=9D make it better? >>> It is based on telemetry information which is embedded within live >>> data packets. >> >> There's a mention of "active probing" further down. You might want to bring that up here, to help the reader understand the scope of the work. >> See above. I'm still confused from the charter text as to whether this effort includes injected traffic. I'm happy to wait until you folks spin a revision to see whether I've gotten any smarter :-) >>> The IOAM WG intends to define data formats and associated >>> procedures for in-situ OAM, including mechanisms for capturing path and >>> path-traversal related information as well as procedures to employ, >>> configure, trigger, and export the embedded telemetry information. >>> >>> The IOAM WG will define the following in-situ OAM components: >>> >>> * Data-records for in-situ OAM to cover path-tracing and path >>> verification information (node-ids, ingress/egress interfaces), >>> timestamps, transit-delay, transit jitter, sequence numbers, >>> application-defined metadata. >> >> Is this intended to be an exhaustive list? I'm guessing that "application-defined metadata" is probably open-ended ... but whether that's true or not, is the working group allowed to define in-situ OAM that covers more than these named path attributes? >> This is a comprehensive but probably not fully exhaustive list. We could clarify this. You might find that helpful. We have a similar list in the QUIC charter, and people find it tempting to use that list as a filter for what's in scope for QUIC, so being clear about whether other path attributes are in scope would likely be helpful for IOAM. >>> In-situ OAM data-records are defined using >>> an in-situ OAM namespace. It should be possible to control the >>> information that gets recorded in data-records. >>> * Procedures to add, update, remove, retrieve and export data-records for >>> in-situ OAM to live traffic and active probing. In case of live traffi= c >>> a classifier to select subset of live traffic for addition, update, >>> removal and retrieval of in-situ OAM data-records. In case of active >>> probing procedure to return the in-situ OAM data records to the source of >>> the probe. >>> * Scope of in-situ OAM operation. In-Situ OAM operations are defined for >>> a specific operational domain. In-situ OAM data-records are added and >>> removed at domain boundaries and updated by nodes within the in-situ OA= M >>> domain. Procedure to deal with various challenges in packet forwarding >>> and error handling such as ECMP processing, path MTU and ICMP message >>> handling when in-situ OAM is enabled in an in-situ OAM domain. >>> * Data-records for in-situ OAM are to be defined in a way that makes >>> them independent from the transport protocol used. Data-records for >>> in-situ OAM will need to be embedded into transport protocols such as >>> IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, Geneve. >> >> Is "transport protocol" the best term here? >> >> I'm not objecting to this because we're not talking about TCP :-) - I'm asking because I don't know what this text is telling me about these protocols. >> >> If that's the clearest term for this problem domain, that's fine, but I had to ask. Thanks for asking. As you surmised, this is not =E2=80=9Ctransport=E2=80=9D= in the context of transport-layer protocols as TCP. In fact, these protocols do not operate at the same layer (or at a defined model layer). Perhaps =E2=80=9Cencapsulation protocols=E2=80=9D is best? I'm not sure whether "encapsulation protocols" is surviving discussion later in the thread, but I think it's an improvement. Thanks for suggesting it. >> >>> * Procedures and data-records optimized for software dataplane and >>> hardware dataplane implementations of in-situ OAM. >>> * In-situ OAM to support layering. If several transport protocols (e.g. >>> in case of tunneling) are stacked on top of each other, in-situ OAM >>> data-records could be present in every transport protocol layer. >>> * Management and control of role of nodes for in-situ OAM operation, >>> dynamic control of in-situ OAM data collected in the data records, data >>> export optimization. >>> >>> The IOAM working group intends to work on and publish: >>> * Definition of the data-type formats used in in-situ OAM and namespace= s >>> for in-situ OAM. >>> * Definition of procedures that in-situ OAM enabled nodes will perform on >>> data traffic that carries in-situ OAM information (e.g., introducing, >>> removing, processing, modifying, and exporting the telemetry informatio= n >>> from the associated data packets). >>> * Configuration and operational data models for controlling in-situ OAM >>> data and operations. >>> In-situ OAM data records could be embedded into a variety of transports= . >>> The transports are expected to be defined in the respective working >>> group(s) like NVO3, SFC, 6man, MPLS etc in consultation with the IOAM >>> working group documents. IOAM WG exclusively focuses on mechanisms whic= h >>> piggyback OAM-related metadata onto en-route traffic for OAM purposes. >>> Other ongoing OAM-related efforts in working groups(s) such as MPLS and >>> IPPM that do not piggyback information onto the live user data traffic >>> are out of scope of the IOAM WG. >> >> It may be useful to call out TSVWG, because they've been consulting on various tunneling protocols. >> I am not sure there is a strong connection to TSVWG =E2=80=94 but on the ot= her hand, it might not hurt to call it out. I was actually thinking about other reasons to include TSVWG, but just to cover one question - I'm assuming that adding IOAM attributes to a user data packet will increase the MTU size. If that's true, that point alone would make TSVWG awareness worth calling out. >> Is there any connection with IPPM? Yes, there is, as already mentioned above. I see that this linkage is under discussion further down, so I'll comment there if I have something to contribute. Thanks for the speedy response! Spencer Thanks! =E2=80=94 Carlos. >> >>> Milestones >>> >>> April 2018 - submit data format and associated procedures document to >>> IESG. >>> March 2018 - WGLC for data format and associated procedures document. >>> April 2017 - working group adoption of data format and associated >>> procedures document >>> >>> Milestones: > _______________________________________________ > Ioam mailing list > Ioam@ietf.org > https://www.ietf.org/mailman/listinfo/ioam --001a114edf24d728b5054830056c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've read through this thread to the bottom as o= f the time I'm sending this note, but just to wrap up my own questions = ...

On Feb 9, = 2017 11:18, "Carlos Pignataro (cpignata)" <cpignata@cisco.com> wrote:
Thanks, Alvaro.

Hi, Spencer,

Please find some follow-ups inline. Look forward to understanding if they c= larify, or what specific suggestions can make the charter text better.

=E2=80=94
Carlos Pignataro, carlos@cisco.com<= br>
=E2=80=9CSometimes I use big words that I do not fully understand, to make = myself sound more photosynthesis."

> On Feb 9, 2017, at 10:57 AM, Alvaro Retana (aretana) <aretana@cisco.com> wrote:
>
> Spencer:
>
> Hi!=C2=A0 I=E2=80=99m cc=E2=80=99ing the list to get feedback from the= m.
>
> Thanks for your comments!
>
> Alvaro.
>
>> On 2/8/17, 2:32 PM, "iesg on= behalf of Spencer Dawkins at IETF" <iesg-bounces@ietf.org on behalf ofspencerdawkins.ietf@gmail.com> wrote:<= br> >>
>> So, thinking about this some more ...
>>
>> Most of what follows is questions, so you may be educating me in m= ost of the cases, instead of changing text in the proposed charter.
>>
>> On Wed, Feb 8, 2017 at 12:32 PM, IETF Secretariat <ietf-secretariat-reply@ietf.org= > wrote:
>>>
>>>
>>> A new IETF WG is being considered in the IETF. The draft chart= er for this
>>> WG is provided below for your review and comment.
>>>
>>> Review time is one week.
>>>
>>> The IETF Secretariat
>>>
>>> In-situ OAM (ioam)
>>> ---------------------------------------------------------= --------------
>>> Current status: Proposed WG
>>>
>>> Chairs:
>>>=C2=A0 =C2=A0TBD
>>>
>>> Assigned Area Director:
>>>=C2=A0 =C2=A0Alvaro Retana <aretana@cisco.com>
>>>
>>> Routing Area Directors:
>>>=C2=A0 =C2=A0Alia Atlas <akatlas@gmail.com>
>>>=C2=A0 =C2=A0Alvaro Retana <aretana@cisco.com>
>>>=C2=A0 =C2=A0Deborah Brungard <db3546@att.com>
>>>
>>> Mailing list:
>>>=C2=A0 =C2=A0Address: ioam@iet= f.org
>>>=C2=A0 =C2=A0To subscribe: https://www.ietf.or= g/mailman/listinfo/ioam
>>>=C2=A0 =C2=A0Archive: https://mailarchive.= ietf.org/arch/browse/ioam/
>>>
>>> Charter: https://datatracker.ietf.or= g/doc/charter-ietf-ioam/
>>>
>>> In-situ OAM provides real-time telemetry of individual data pa= ckets and
>>> flows.
>>
>> Is it true to say that In-situ OAM provides real-time telemetry of= individual data packets and flows, based on information embedded within li= ve data packets?
>>

In-situ OAM records telemetry information by embedding it into actual= data packets (as opposed to synthetic probes). In that context, I=E2=80=99= d say it is true =E2=80=94 however, see below.

The clearest term I've seen pop up i= n this thread is "user data packets". I'd suggest that you co= nsider adopting that term.


>> I'm reading the current text as saying that this can do OAM fo= r an individual packet. I don't even know what that means.
>>
>> I'm not quite sure I understand what a "live" data p= acket is. Is the point that this isn't injecting measurement traffic (s= o, "passive", rather than "active" - or is the text cal= ling that "active probing")? But I'm guessing.
>>

Perhaps =E2=80=9Clive=E2=80=9D is the distractor here. I do wonder if= =E2=80=9Cactual=E2=80=9D might make it clearer.

The challenge is that In-situ OAM is neither =E2=80=9Cactive=E2=80=9D not = =E2=80=9Cpassive=E2=80=9D measurement.
Passive means =E2=80=98solely by observation and without modification to th= e packet=E2=80=99 (https://= tools.ietf.org/html/draft-ietf-ippm-active-passive-06#section-3.6= ).
Active means =E2=80=98generating (accompanying / synthetic) packet streams= =E2=80=99 (https://tools.ie= tf.org/html/draft-ietf-ippm-active-passive-06#section-3.4).
Thus, In-situ OAM is its own class.

Based on this, do you have another recommendation? Does =E2=80=9Cactual=E2= =80=9D instead of =E2=80=9Cactive=E2=80=9D make it better?

>>> It is based on telemetry information which is embedded within = live
>>> data packets.
>>
>> There's a mention of "active probing" further down. = You might want to bring that up here, to help the reader understand the sco= pe of the work.
>>

See above.

I'm still confused from the charter = text as to whether this effort includes injected traffic. I'm happy to = wait until you folks spin a revision to see whether I've gotten any sma= rter :-)


>>> The IOAM WG intends to define data formats and associated
>>> procedures for in-situ OAM, including mechanisms for capturing= path and
>>> path-traversal related information as well as procedures to em= ploy,
>>> configure, trigger, and export the embedded telemetry informat= ion.
>>>
>>> The IOAM WG will define the following in-situ OAM components:<= br> >>>
>>> * Data-records for in-situ OAM to cover path-tracing and path<= br> >>> verification information (node-ids, ingress/egress interfaces)= ,
>>> timestamps, transit-delay, transit jitter, sequence numbers, >>> application-defined metadata.
>>
>> Is this intended to be an exhaustive list? I'm guessing that &= quot;application-defined metadata" is probably open-ended ... but whet= her that's true or not, is the working group allowed to define in-situ = OAM that covers more than these named path attributes?
>>

This is a comprehensive but probably not fully exhaustive list. We co= uld clarify this.

You might find that helpful. We have a s= imilar list in the QUIC charter, and people find it tempting to use that li= st as a filter for what's in scope for QUIC, so being clear about wheth= er other path attributes are in scope would likely be helpful for IOAM.

=

>>> In-situ OAM data-records are defined using
>>> an in-situ OAM namespace. It should be possible to control the=
>>> information that gets recorded in data-records.
>>> * Procedures to add, update, remove, retrieve and export data-= records for
>>> in-situ OAM to live traffic and active probing.=C2=A0 In case = of live traffic
>>> a classifier to select subset of live traffic for addition, up= date,
>>> removal and retrieval of in-situ OAM data-records. In case of = active
>>> probing procedure to return the in-situ OAM data records to th= e source of
>>> the probe.
>>> *=C2=A0 Scope of in-situ OAM operation. In-Situ OAM operations= are defined for
>>> a specific operational domain. In-situ OAM data-records are ad= ded and
>>> removed at domain boundaries and updated by nodes within the i= n-situ OAM
>>> domain. Procedure to deal with various challenges in packet fo= rwarding
>>> and error handling such as ECMP processing, path MTU and ICMP = message
>>> handling when in-situ OAM is enabled in an in-situ OAM domain.=
>>> *=C2=A0 Data-records for in-situ OAM are to be defined in a wa= y that makes
>>> them independent from the transport protocol used. Data-record= s for
>>> in-situ OAM will need to be embedded into transport protocols = such as
>>> IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, Geneve.
>>
>> Is "transport protocol" the best term here?
>>
>> I'm not objecting to this because we're not talking about = TCP :-) - I'm asking because I don't know what this text is telling= me about these protocols.
>>
>> If that's the clearest term for this problem domain, that'= s fine, but I had to ask.

Thanks for asking. As you surmised, this is not =E2=80=9Ctransport=E2= =80=9D in the context of transport-layer protocols as TCP. In fact, these p= rotocols do not operate at the same layer (or at a defined model layer).
Perhaps =E2=80=9Cencapsulation protocols=E2=80=9D is best?

I'm not sure whether "encapsula= tion protocols" is surviving discussion later in the thread, but I thi= nk it's an improvement. Thanks for suggesting it.


>>
>>> * Procedures and data-records optimized for software dataplane= and
>>> hardware dataplane implementations of in-situ OAM.
>>> * In-situ OAM to support layering. If several transport protoc= ols (e.g.
>>> in case of tunneling) are stacked on top of each other, in-sit= u OAM
>>> data-records could be present in every transport protocol laye= r.
>>> * Management and control of role of nodes for in-situ OAM oper= ation,
>>> dynamic control of in-situ OAM data collected in the data reco= rds, data
>>> export optimization.
>>>
>>> The IOAM working group intends to work on and publish:
>>> * Definition of the data-type formats used in in-situ OAM and = namespaces
>>> for in-situ OAM.
>>> * Definition of procedures that in-situ OAM enabled nodes will= perform on
>>> data traffic that carries in-situ OAM information (e.g., intro= ducing,
>>> removing, processing, modifying, and exporting the telemetry i= nformation
>>> from the associated data packets).
>>> * Configuration and operational data models for controlling in= -situ OAM
>>> data and operations.
>>> In-situ OAM data records could be embedded into a variety of t= ransports.
>>> The transports are expected to be defined in the respective wo= rking
>>> group(s) like NVO3, SFC, 6man, MPLS etc in consultation with t= he IOAM
>>> working group documents. IOAM WG exclusively focuses on mechan= isms which
>>> piggyback OAM-related metadata onto en-route traffic for OAM p= urposes.
>>> Other ongoing OAM-related efforts in working groups(s) such as= MPLS and
>>> IPPM that do not piggyback information onto the live user data= traffic
>>> are out of scope of the IOAM WG.
>>
>> It may be useful to call out TSVWG, because they've been consu= lting on various tunneling protocols.
>>

I am not sure there is a strong connection to TSVWG =E2=80=94 but on = the other hand, it might not hurt to call it out.
<= /div>

I was actually thinking = about other reasons to include TSVWG, but just to cover one question - I= 9;m assuming that adding IOAM attributes to a user data packet will increas= e the MTU size. If that's true, that point alone would make TSVWG aware= ness worth calling out.

=
>> Is there any connection with IPPM?

Yes, there is, as already mentioned above.

I see that this linka= ge is under discussion further down, so I'll comment there if I have so= mething to contribute.

T= hanks for the speedy response!

Spencer

Thanks!

=E2=80=94 Carlos.

>>
>>> Milestones
>>>
>>> April 2018 - submit data format and associated procedures docu= ment to
>>> IESG.
>>> March 2018 - WGLC for data format and associated procedures do= cument.
>>> April 2017 - working group adoption of data format and associa= ted
>>> procedures document
>>>
>>> Milestones:
> _______________________________________________
> Ioam mailing list
> Ioam@ietf.org
> https://www.ietf.org/mailman/listinfo/ioam

--001a114edf24d728b5054830056c-- From nobody Fri Feb 10 09:09:30 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCD6129A47; Fri, 10 Feb 2017 09:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 slDcbt1VNlE2; Fri, 10 Feb 2017 09:09:23 -0800 (PST) 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 7112B127058; Fri, 10 Feb 2017 09:09:23 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id w204so24345859oiw.0; Fri, 10 Feb 2017 09:09:23 -0800 (PST) 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=Eq7mMgc2I01v8UoXE3CePrYgJT+so3OXiiHkLbP+TUA=; b=T39Pza2/SoNxXAEKsT1JlzF+TjqQSNnP5g4Hg7RAhxuNEY0Jz6ZgRQs0Mcw/OufwQx SMBWGRNJ8Jit/W56KWX65RgrXviIiNiLMHVyULqFlRJ4guFBA9SfSzwGA/ITrO8+lFd7 ZvJ62rYvhpKtJ0Aew9rMon84j257eFqokEsfGLyJODm8oz2YIgHSlZfq5/ozrQgUQhoP 3PJ/ETL5WNmgG3NJtv4D+eXCB+w70FQ21/GCwrr7ZUv1H+YVwqOJOEzhPMTAepGfpMBP qNPXIlHgv1zhgSAn/xNudCN2QCyD0aHT5IAUALgQ+JHhP0uC+m9wJ/p4bPZpibXFumzP 3ZrA== 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=Eq7mMgc2I01v8UoXE3CePrYgJT+so3OXiiHkLbP+TUA=; b=ac5G32a4jTD2NC7v0/VcUYaUafXG1fQgNXICS4N6l7pHl9mwdVYU15yODQ/jXVKI19 pwy9ijQsRTt9aYERMc/qjEptd6XMZimtHn/2Ce0uBNbcIH6dOxN1Mt2VfFOJ73AkhpiB Xyl3uHX/zD9zJ0Rs+ZHOAIRp4RbvoM2JGnfxSDBzkcHeTDBn45zyNKqjp9MeNxnQBktA kfdlthmfEWpxkO1IIYP2ZUZviPXCRQFIUBH3aHJ2xfdIznMUGWau1kXXDzttXDl7Oxan YJK2IQywHxyHZX2CGrasyKJVibvRiJ0cyEfk9OeEiEx/WfcBeHX1tXUkbyGdv1pCTCIC Xneg== X-Gm-Message-State: AMke39mYjitV2PmPq+xV6YFq3b70WjkgriMUsw8F5HoourzQ7xqxgQR6baVMjvCShr7cikR3x6uG/ypoyVKARA== X-Received: by 10.202.0.140 with SMTP id 134mr5729717oia.84.1486746562707; Fri, 10 Feb 2017 09:09:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.1 with HTTP; Fri, 10 Feb 2017 09:09:22 -0800 (PST) In-Reply-To: <9826D9EC-E161-48A6-AC5B-EA0C73BFE526@kuehlewind.net> References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> <0bdcfd0be2c84ffa81b1658af60f084d@XCH-RCD-008.cisco.com> <9826D9EC-E161-48A6-AC5B-EA0C73BFE526@kuehlewind.net> From: Ram Krishnan Date: Fri, 10 Feb 2017 09:09:22 -0800 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary=001a1137a350bdc90d054830280b Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "Frank Brockners \(fbrockne\)" , The IAB , "iesg@ietf.org" , "ioam@ietf.org" , "Alvaro Retana \(aretana\)" , Spencer Dawkins at IETF Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 17:09:25 -0000 --001a1137a350bdc90d054830280b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Very good discussion. Another aspect to note is that we see value for in-situ OAM for monitoring network functions (especially virtual) besides network interconnects. This is captured in Section 3 in the draft ( https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro-sla/?inc= lude_text=3D1 ). I believe IPPM charter addresses only network monitoring. Thanks, Ramki On Fri, Feb 10, 2017 at 7:11 AM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi Frank, hi all, > > please see in-line. > > > Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne) < > fbrockne@cisco.com>: > > > > Hi Mirja, > > > > you raise an interesting point. The IPPM charter states " Specifying > network or lower layer OAM mechanisms is out of scope of the IPPM > charter.", whereas the WG has " Submit a draft on the IPv6 Performance an= d > Diagnostic Metrics (PDM) Destination Option as Proposed Standard > > draft-ietf-ippm-6man-pdm-option" as a milestone. I'd assume that we'd > likely qualify IPv6 as a transport protocol=E2=80=A6 > > If you also cite the sentence before this, this might become clearer: > > "The IP Performance Metrics (IPPM) Working Group develops and maintains > standard metrics that can be applied to the quality, performance, and > reliability of Internet data delivery services and applications running > over transport layer protocols (e.g. TCP, UDP) over IP. Specifying networ= k > or lower layer OAM mechanisms is out of scope of the IPPM charter.=E2=80= =9C > > It=E2=80=99s focused on performance measurements of data delivery service= s and > application, not metric sthat are specific to network operation e.g. > up-time of a router (as an example that just came to my mind). > > So to me the scope and the goals of IPPM and IOAM are overlapping > currently as for me "real-time telemetry of individual data packets and > flows=E2=80=9C is exactly what IPPM is doing. > > > > > So far I understood the main focus of the new IOAM WG to be > network-layer focused, i.e. piggyback OAM-meta-data onto network-layer > protocols - but that does not necessarily need to be always the case as y= ou > implicitly highlight by drawing the link to IPPM. One could also do so > using e.g. TCP options. I did not read the statement on IPPM in the draft > charter as "not cooperating with IPPM" - I read it in a way that methods > that do not piggyback information on live traffic are not considered in > IOAM. That said, especially when it comes to export and interpretation of > in-situ OAM data, there might indeed be common ground between IOAM and IP= PM. > > My point is not that there needs to be cooperation. My point is that we > already have a working group that is mostly charter to do what you want t= o > do. > > Mirja > > > > > > How about we add another sentence to the charter that underlines the > fact that IOAM would actively seek cooperation with other related efforts= ? > We could add something like: > > > > "The IOAM WG seeks cooperation with other appropriate standards bodies > and forums to promote consistent approaches, as well as definition and > interpretation of in-situ OAM data." > > > > This would naturally capture IETF WGs like IPPM - but also efforts like > INT in P4, hence we'd even cast the net a little wider. > > > > Thoughts? > > > > Thanks, Frank > > > > -----Original Message----- > > From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Mirja Kuehlewind > (IETF) > > Sent: Freitag, 10. Februar 2017 13:10 > > To: Carlos Pignataro (cpignata) ; Alvaro Retana > (aretana) > > Cc: iesg@ietf.org; The IAB ; Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com>; ioam@ietf.org > > Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) > > > > Hi all, > > > > also one more comment on this point: > > > >> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata) < > cpignata@cisco.com>: > >> > >>>> Is there any connection with IPPM? > >> > >> Yes, there is, as already mentioned above. > > > > > > The charter currently says: > > > > "Other ongoing OAM-related efforts in working groups(s) such as MPLS an= d > IPPM that do not piggyback information onto the live user data traffic ar= e > out of scope of the IOAM WG.=E2=80=9C > > > > which indictates that cooperation with IPPM is not planned. > > > > To me in general the relation between this work and other ongoing work > in the IETF is not very clear and IPPM has several documents and mileston= es > that are in scope for this work: > > > > - Submit a draft on the IPv6 Performance and Diagnostic Metrics (PDM) > Destination Option as Proposed Standard: draft-ietf-ippm-6man-pdm-option > (this draft is mainly done and silenter the publication process soon to m= y > understanding) > > > > - Submit an Experimental draft on coloring-based hybrid measurement > methodologies for loss and delay to the IESG: draft-ietf-ippm-alt-mark-03 > > > > I don=E2=80=99t think that the assessment in the charter that IPPM's sc= ope does > not include piggybacked information is correct. Looking at > draft-brockners-inband-oam-transport-02, I think that any work on IPV6 > and IPv6 in this scope should be done in IPPM because that=E2=80=99s were= this work > is already on-going and where the measurement expertise is. > > > > Mirja > > > > > > > > > > _______________________________________________ > > Ioam mailing list > > Ioam@ietf.org > > https://www.ietf.org/mailman/listinfo/ioam > > _______________________________________________ > Ioam mailing list > Ioam@ietf.org > https://www.ietf.org/mailman/listinfo/ioam > --=20 Thanks, Ramki --001a1137a350bdc90d054830280b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Very good discussion.=C2=A0

<= /div>
Another aspect to note is that we see value for in-situ OAM = for monitoring network functions (especially virtual) besides network inter= connects. This is captured in Section 3 in the draft (https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro-sl= a/?include_text=3D1).=C2=A0

I believ= e IPPM charter addresses only network monitoring.

=
Thanks,
Ramki

=
On Fri, Feb 10, 2017 at 7:11 AM, Mirja Kuehlewin= d (IETF) <ietf@kuehlewind.net> wrote:
Hi Frank, hi all,

please see in-line.

> Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne) <fbrockne@cisco.com>:
>
> Hi Mirja,
>
> you raise an interesting point. The IPPM charter states=C2=A0 " S= pecifying network or lower layer OAM mechanisms is out of scope of the IPPM= charter.", whereas the WG has " Submit a draft on the IPv6 Perfo= rmance and Diagnostic Metrics (PDM) Destination Option as Proposed Standard=
> draft-ietf-ippm-6man-pdm-option" as a milestone. I'd ass= ume that we'd likely qualify IPv6 as a transport protocol=E2=80=A6

If you also cite the sentence before this, this might become clearer:

"The IP Performance Metrics (IPPM) Working Group develops and maintain= s
standard metrics that can be applied to the quality, performance, and
reliability of Internet data delivery services and applications running
over transport layer protocols (e.g. TCP, UDP) over IP. Specifying network<= br> or lower layer OAM mechanisms is out of scope of the IPPM charter.=E2=80=9C=

It=E2=80=99s focused on performance measurements of data delivery services = and application, not metric sthat are specific to network operation e.g. up= -time of a router (as an example that just came to my mind).

So to me the scope and the goals of IPPM and IOAM are overlapping currently= as for me "real-time telemetry of individual data packets and flows= =E2=80=9C is exactly what IPPM is doing.

>
> So far I understood the main focus of the new IOAM WG to be network-la= yer focused, i.e. piggyback OAM-meta-data onto network-layer protocols - bu= t that does not necessarily need to be always the case as you implicitly hi= ghlight by drawing the link to IPPM. One could also do so using e.g. TCP op= tions. I did not read the statement on IPPM in the draft charter as "n= ot cooperating with IPPM" - I read it in a way that methods that do no= t piggyback information on live traffic are not considered in IOAM. That sa= id, especially when it comes to export and interpretation of in-situ OAM da= ta, there might indeed be common ground between IOAM and IPPM.

My point is not that there needs to be cooperation. My point is that we alr= eady have a working group that is mostly charter to do what you want to do.=

Mirja


>
> How about we add another sentence to the charter that underlines the f= act that IOAM would actively seek cooperation with other related efforts? W= e could add something like:
>
> "The IOAM WG seeks cooperation with other appropriate standards b= odies and forums to promote consistent approaches, as well as definition an= d interpretation of in-situ OAM data."
>
> This would naturally capture IETF WGs like IPPM - but also efforts lik= e INT in P4, hence we'd even cast the net a little wider.
>
> Thoughts?
>
> Thanks, Frank
>
> -----Original Message-----
> From: Ioam [mailto:ioam-bounc= es@ietf.org] On Behalf Of Mirja Kuehlewind (IETF)
> Sent: Freitag, 10. Februar 2017 13:10
> To: Carlos Pignataro (cpignata) <cpignata@cisco.com>; Alvaro Retana (aretana) <aretana@cisco.com>
> Cc: iesg@ietf.org; The IAB <iab@iab.org>; Spencer Dawkins at IETF &= lt;spencerdawkins.ietf@gma= il.com>; ioam@ietf.org
> Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam)
>
> Hi all,
>
> also one more comment on this point:
>
>> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata) <cpignata@cisco.com>:
>>
>>>> Is there any connection with IPPM?
>>
>> Yes, there is, as already mentioned above.
>
>
> The charter currently says:
>
> "Other ongoing OAM-related efforts in working groups(s) such as M= PLS and IPPM that do not piggyback information onto the live user data traf= fic are out of scope of the IOAM WG.=E2=80=9C
>
> which indictates that cooperation with IPPM is not planned.
>
> To me in general the relation between this work and other ongoing work= in the IETF is not very clear and IPPM has several documents and milestone= s that are in scope for this work:
>
> - Submit a draft on the IPv6 Performance and Diagnostic Metrics (PDM) = Destination Option as Proposed Standard: draft-ietf-ippm-6man-pdm-opti= on (this draft is mainly done and silenter the publication process soon to = my understanding)
>
> - Submit an Experimental draft on coloring-based hybrid measurement me= thodologies for loss and delay to the IESG: draft-ietf-ippm-alt-mark-03
>
> I don=E2=80=99t think that the assessment in the charter that IPPM'= ;s scope does not include piggybacked information is correct. Looking at dr= aft-brockners-inband-oam-transport-02, I think that any work on IPV6 a= nd IPv6 in this scope should be done in IPPM because that=E2=80=99s were th= is work is already on-going and where the measurement expertise is.
>
> Mirja
>
>
>
>
> _______________________________________________
> Ioam mailing list
> Ioam@ietf.org
> https://www.ietf.org/mailman/listinfo/ioam
_______________________________________________
Ioam mailing list
Ioam@ietf.org
https://www.ietf.org/mailman/listinfo/ioam



--
Thanks,=C2=A0
Ramki
--001a1137a350bdc90d054830280b-- From nobody Fri Feb 10 09:19:42 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E5B129A60; Fri, 10 Feb 2017 09:19:37 -0800 (PST) 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 e_dXP7d9QaKw; Fri, 10 Feb 2017 09:19:35 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 7C984129A5E; Fri, 10 Feb 2017 09:19:34 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id v200so24822169ywc.3; Fri, 10 Feb 2017 09:19:34 -0800 (PST) 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=ycVwqAEMD2TMPaC65rU40ih0ndhVuv0ki4VYemEPPsA=; b=rr7gMXvgIM2its/LxliqvIwiU5l1T2w3v1CONULCk39Aa5NGc8V7Eta65x995nZhcy EMmyxrVYwLCOFumMTV/h7DQa49B2e7mEznmv+1INfhCfP3Fd81NYTTSVfPl6yOEcKrOf EnXQHAZZ2CmZAQ77TMS31tuTsK8ed5cbbGO75PRk36e/vBEeBQXy0Ow0bCWsgn35BNLY 8ii8ulWgGkWMIjes7qZLF5K9lDWMY5nAO6tezLopdGdKVaEPnkL3AoWe9I4dVLvVthm1 DLfbUoe0lI1bFpg+PVeWfOQDb/OD+JK1UVva5+3ubE5pamgL6BKZtzNry9vZskNWUGyx vhmQ== 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=ycVwqAEMD2TMPaC65rU40ih0ndhVuv0ki4VYemEPPsA=; b=CQP0uWC7WXMQPPCkgK2kyrj/RAFpb6INRgypxuFXf8mnRUc6y7aEeZ0UH/YV3Tzi+v yvO9GbH9dVfEOxrFf9VbX0jbd71hmCIA0yWg/Hi/8QQId0CaftPVRQuy4HIZLg8vagro 3YxfUMO1+Sll78JALb4WtNi3WU+p5TyzqPIfcueP7mRyejLnDrXBcHr/4SQ4jMrVro+2 IybaavL5B1nOwp4oy8nyggD1u+1jlrzQN0XnjjBKYVjuyr385DuHXZCriE+ml/wC3LC+ duzmnVwRbApLwrr80Xe4K9t4SNObc/OiR6GGjuMXbArHuHX3lLxfcCA9y8LqADU7rdZu 9OQA== X-Gm-Message-State: AMke39n/KgpF987xYQ4FwKRKwQr9kgZ8kzumbLjScnQG+xo1fS7lz/SbYQDK7PHyl+64MHeWfyImJkt2idcudQ== X-Received: by 10.129.162.130 with SMTP id z124mr7957553ywg.276.1486747173738; Fri, 10 Feb 2017 09:19:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.234.9 with HTTP; Fri, 10 Feb 2017 09:19:33 -0800 (PST) Received: by 10.37.234.9 with HTTP; Fri, 10 Feb 2017 09:19:33 -0800 (PST) In-Reply-To: References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> <0bdcfd0be2c84ffa81b1658af60f084d@XCH-RCD-008.cisco.com> <9826D9EC-E161-48A6-AC5B-EA0C73BFE526@kuehlewind.net> From: Spencer Dawkins at IETF Date: Fri, 10 Feb 2017 11:19:33 -0600 Message-ID: To: Ram Krishnan Content-Type: multipart/alternative; boundary=94eb2c1292922975e60548304d85 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "Frank Brockners \(fbrockne\)" , The IAB , Mirja Kuehlewind , "iesg@ietf.org" , "ioam@ietf.org" , "Alvaro Retana \(aretana\)" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 17:19:38 -0000 --94eb2c1292922975e60548304d85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Ram, On Feb 10, 2017 11:09, "Ram Krishnan" wrote: Very good discussion. Another aspect to note is that we see value for in-situ OAM for monitoring network functions (especially virtual) besides network interconnects. This is captured in Section 3 in the draft (https://datatracker.ietf.org/ doc/draft-krishnan-opsawg-in-band-pro-sla/?include_text=3D1). I believe IPPM charter addresses only network monitoring. The responsible AD for IPPM happens to agree :-) Is the expertise required for path monitoring the same as the expertise required for network element monitoring? Thanks, Spencer Thanks, Ramki On Fri, Feb 10, 2017 at 7:11 AM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi Frank, hi all, > > please see in-line. > > > Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne) < > fbrockne@cisco.com>: > > > > Hi Mirja, > > > > you raise an interesting point. The IPPM charter states " Specifying > network or lower layer OAM mechanisms is out of scope of the IPPM > charter.", whereas the WG has " Submit a draft on the IPv6 Performance an= d > Diagnostic Metrics (PDM) Destination Option as Proposed Standard > > draft-ietf-ippm-6man-pdm-option" as a milestone. I'd assume that we'd > likely qualify IPv6 as a transport protocol=E2=80=A6 > > If you also cite the sentence before this, this might become clearer: > > "The IP Performance Metrics (IPPM) Working Group develops and maintains > standard metrics that can be applied to the quality, performance, and > reliability of Internet data delivery services and applications running > over transport layer protocols (e.g. TCP, UDP) over IP. Specifying networ= k > or lower layer OAM mechanisms is out of scope of the IPPM charter.=E2=80= =9C > > It=E2=80=99s focused on performance measurements of data delivery service= s and > application, not metric sthat are specific to network operation e.g. > up-time of a router (as an example that just came to my mind). > > So to me the scope and the goals of IPPM and IOAM are overlapping > currently as for me "real-time telemetry of individual data packets and > flows=E2=80=9C is exactly what IPPM is doing. > > > > > So far I understood the main focus of the new IOAM WG to be > network-layer focused, i.e. piggyback OAM-meta-data onto network-layer > protocols - but that does not necessarily need to be always the case as y= ou > implicitly highlight by drawing the link to IPPM. One could also do so > using e.g. TCP options. I did not read the statement on IPPM in the draft > charter as "not cooperating with IPPM" - I read it in a way that methods > that do not piggyback information on live traffic are not considered in > IOAM. That said, especially when it comes to export and interpretation of > in-situ OAM data, there might indeed be common ground between IOAM and IP= PM. > > My point is not that there needs to be cooperation. My point is that we > already have a working group that is mostly charter to do what you want t= o > do. > > Mirja > > > > > > How about we add another sentence to the charter that underlines the > fact that IOAM would actively seek cooperation with other related efforts= ? > We could add something like: > > > > "The IOAM WG seeks cooperation with other appropriate standards bodies > and forums to promote consistent approaches, as well as definition and > interpretation of in-situ OAM data." > > > > This would naturally capture IETF WGs like IPPM - but also efforts like > INT in P4, hence we'd even cast the net a little wider. > > > > Thoughts? > > > > Thanks, Frank > > > > -----Original Message----- > > From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Mirja Kuehlewind > (IETF) > > Sent: Freitag, 10. Februar 2017 13:10 > > To: Carlos Pignataro (cpignata) ; Alvaro Retana > (aretana) > > Cc: iesg@ietf.org; The IAB ; Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com>; ioam@ietf.org > > Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) > > > > Hi all, > > > > also one more comment on this point: > > > >> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata) < > cpignata@cisco.com>: > >> > >>>> Is there any connection with IPPM? > >> > >> Yes, there is, as already mentioned above. > > > > > > The charter currently says: > > > > "Other ongoing OAM-related efforts in working groups(s) such as MPLS an= d > IPPM that do not piggyback information onto the live user data traffic ar= e > out of scope of the IOAM WG.=E2=80=9C > > > > which indictates that cooperation with IPPM is not planned. > > > > To me in general the relation between this work and other ongoing work > in the IETF is not very clear and IPPM has several documents and mileston= es > that are in scope for this work: > > > > - Submit a draft on the IPv6 Performance and Diagnostic Metrics (PDM) > Destination Option as Proposed Standard: draft-ietf-ippm-6man-pdm-option > (this draft is mainly done and silenter the publication process soon to m= y > understanding) > > > > - Submit an Experimental draft on coloring-based hybrid measurement > methodologies for loss and delay to the IESG: draft-ietf-ippm-alt-mark-03 > > > > I don=E2=80=99t think that the assessment in the charter that IPPM's sc= ope does > not include piggybacked information is correct. Looking at > draft-brockners-inband-oam-transport-02, I think that any work on IPV6 > and IPv6 in this scope should be done in IPPM because that=E2=80=99s were= this work > is already on-going and where the measurement expertise is. > > > > Mirja > > > > > > > > > > _______________________________________________ > > Ioam mailing list > > Ioam@ietf.org > > https://www.ietf.org/mailman/listinfo/ioam > > _______________________________________________ > Ioam mailing list > Ioam@ietf.org > https://www.ietf.org/mailman/listinfo/ioam > --=20 Thanks, Ramki --94eb2c1292922975e60548304d85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Ram,

On Feb 10, 2017 11:09, "Ram Krishnan" <ramkri123@gmail.com> wrote:
Very = good discussion.=C2=A0

Another aspect to= note is that we see value for in-situ OAM for monitoring network functions= (especially virtual) besides network interconnects. This is captured in Se= ction 3 in the draft (https://d= atatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro-sla/?in= clude_text=3D1).=C2=A0

I believ= e IPPM charter addresses only network monitoring.

The responsible AD for IPPM happens to agree :-)

Is the expertise required for path monitoring = the same as the expertise required for network element monitoring?

Thanks,
<= br>
Spencer


Thanks,
=
Ramki
=
On Fri, Feb 10, 2017 at 7:11 AM, Mirja Kuehl= ewind (IETF) <ietf@kuehlewind.net> wrote:
Hi Frank, hi all,

please see in-line.

> Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne) <fbrockne@cisco.com>= :
>
> Hi Mirja,
>
> you raise an interesting point. The IPPM charter states=C2=A0 " S= pecifying network or lower layer OAM mechanisms is out of scope of the IPPM= charter.", whereas the WG has " Submit a draft on the IPv6 Perfo= rmance and Diagnostic Metrics (PDM) Destination Option as Proposed Standard=
> draft-ietf-ippm-6man-pdm-option" as a milestone. I'd ass= ume that we'd likely qualify IPv6 as a transport protocol=E2=80=A6

If you also cite the sentence before this, this might become clearer:

"The IP Performance Metrics (IPPM) Working Group develops and maintain= s
standard metrics that can be applied to the quality, performance, and
reliability of Internet data delivery services and applications running
over transport layer protocols (e.g. TCP, UDP) over IP. Specifying network<= br> or lower layer OAM mechanisms is out of scope of the IPPM charter.=E2=80=9C=

It=E2=80=99s focused on performance measurements of data delivery services = and application, not metric sthat are specific to network operation e.g. up= -time of a router (as an example that just came to my mind).

So to me the scope and the goals of IPPM and IOAM are overlapping currently= as for me "real-time telemetry of individual data packets and flows= =E2=80=9C is exactly what IPPM is doing.

>
> So far I understood the main focus of the new IOAM WG to be network-la= yer focused, i.e. piggyback OAM-meta-data onto network-layer protocols - bu= t that does not necessarily need to be always the case as you implicitly hi= ghlight by drawing the link to IPPM. One could also do so using e.g. TCP op= tions. I did not read the statement on IPPM in the draft charter as "n= ot cooperating with IPPM" - I read it in a way that methods that do no= t piggyback information on live traffic are not considered in IOAM. That sa= id, especially when it comes to export and interpretation of in-situ OAM da= ta, there might indeed be common ground between IOAM and IPPM.

My point is not that there needs to be cooperation. My point is that we alr= eady have a working group that is mostly charter to do what you want to do.=

Mirja


>
> How about we add another sentence to the charter that underlines the f= act that IOAM would actively seek cooperation with other related efforts? W= e could add something like:
>
> "The IOAM WG seeks cooperation with other appropriate standards b= odies and forums to promote consistent approaches, as well as definition an= d interpretation of in-situ OAM data."
>
> This would naturally capture IETF WGs like IPPM - but also efforts lik= e INT in P4, hence we'd even cast the net a little wider.
>
> Thoughts?
>
> Thanks, Frank
>
> -----Original Message-----
> From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Mirja Kuehlewind (IETF)
> Sent: Freitag, 10. Februar 2017 13:10
> To: Carlos Pignataro (cpignata) <cpignata@cisco.com>; Alvaro Retana (aretana) &= lt;aretana@cisco.com= >
> Cc: iesg@ietf.org; The IAB <iab@iab.or= g>; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>; = ioam@ietf.org
> Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam)
>
> Hi all,
>
> also one more comment on this point:
>
>> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata) <cpignata@cisco.com= >:
>>
>>>> Is there any connection with IPPM?
>>
>> Yes, there is, as already mentioned above.
>
>
> The charter currently says:
>
> "Other ongoing OAM-related efforts in working groups(s) such as M= PLS and IPPM that do not piggyback information onto the live user data traf= fic are out of scope of the IOAM WG.=E2=80=9C
>
> which indictates that cooperation with IPPM is not planned.
>
> To me in general the relation between this work and other ongoing work= in the IETF is not very clear and IPPM has several documents and milestone= s that are in scope for this work:
>
> - Submit a draft on the IPv6 Performance and Diagnostic Metrics (PDM) = Destination Option as Proposed Standard: draft-ietf-ippm-6man-pdm-option (this draft is mainly done and silenter the publication process soon to = my understanding)
>
> - Submit an Experimental draft on coloring-based hybrid measurement me= thodologies for loss and delay to the IESG: draft-ietf-ippm-alt-mark-03
>
> I don=E2=80=99t think that the assessment in the charter that IPPM'= ;s scope does not include piggybacked information is correct. Looking at dr= aft-brockners-inband-oam-transport-02, I think that any work on IPV6 a= nd IPv6 in this scope should be done in IPPM because that=E2=80=99s were th= is work is already on-going and where the measurement expertise is.
>
> Mirja
>
>
>
>
> _______________________________________________
> Ioam mailing list
> Ioam@ietf.org > https://www.ietf.org/mailman/listinfo/ioam
_______________________________________________
Ioam mailing list
Ioam@ietf.org
https://www.ietf.org/mailman/listinfo/ioam



--
Thanks,=C2=A0
Ramki

--94eb2c1292922975e60548304d85-- From nobody Fri Feb 10 09:37:42 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7901E129A5B; Fri, 10 Feb 2017 09:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 yTWHnl3hhQVe; Fri, 10 Feb 2017 09:37:36 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 821E4129888; Fri, 10 Feb 2017 09:37:36 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id 32so33486533oth.3; Fri, 10 Feb 2017 09:37:36 -0800 (PST) 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=hJWsZVFuclW3JoulX1gzX3R+zZde/WezNW5cRRfqkO0=; b=W55gkT8OXR1VbeDBMWMFR4TDsM1z1WSUFWN5VbhY9IVH6bnHqLko6hsDqZCj4UfUGj +OqrlVRMtfRwUqeLQwIQQ1610G7+KkZM5dDhbKHRn7bDxfCppT7US7Bgg/TDxVPlkzaD Iqzzx6GtGhceBI3b4Isn18s40owrOjnppgt4yXUnRqST17exGsuSwy0+YQT8rS8n3qjx 3NYBx8SegpFvc3NybRfFXCpLXkB2x8aupQzWG+1B7rW15xSarG6/Vj/xsQKA5n30EKA1 bB8Gj9bdkgcN1OGqVidu5MMY1qrFBOqaXcNCnBB/2xZyJrS52Dwk6D2m4a8/ZbjvSxwT lrVw== 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=hJWsZVFuclW3JoulX1gzX3R+zZde/WezNW5cRRfqkO0=; b=tVqc8MX70gMitUwk03TNnbeoWSTb0CsLyQLPvjWlukzvaeMSZQX+4Ok3GFNBpvOmzj OGNQS1ubRE2+3N6DBW1ffcULGqkiK8wxuH7FAq1YG5MdbsVwG4IBWvmBdzbLM78cDffY O1YXHIh7DQAivIB/1zi8jkEwvyudbytVmOG59wZ4hiwpuAHPhOss41pYlor9h1FDVpUz Gtalvht1nWB0+MSk/of1D89LciMb+QBMS9TuoslneihTXmjTfPWwDVG4p/aO0WR7Psa3 GmvV5Bx56DAYC4/P3GeCNjuEaAiwp9Zcn2OG7105ToJwwhDq/BWCaSXI9BA6ljE1gMCR 4avw== X-Gm-Message-State: AMke39nIM6jIxsk+n89XniP5tdk6CdvNPRmCPvHkVunRZz/FUfiOzCuhCYQgytV/rilq7djRTieNa+LOH4FjcA== X-Received: by 10.157.35.74 with SMTP id k10mr5956001otd.113.1486748255847; Fri, 10 Feb 2017 09:37:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.1 with HTTP; Fri, 10 Feb 2017 09:37:35 -0800 (PST) In-Reply-To: References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> <0bdcfd0be2c84ffa81b1658af60f084d@XCH-RCD-008.cisco.com> <9826D9EC-E161-48A6-AC5B-EA0C73BFE526@kuehlewind.net> From: Ram Krishnan Date: Fri, 10 Feb 2017 09:37:35 -0800 Message-ID: To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=001a113d1ceea911450548308dfb Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "Frank Brockners \(fbrockne\)" , The IAB , Mirja Kuehlewind , "iesg@ietf.org" , "ioam@ietf.org" , "Alvaro Retana \(aretana\)" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 17:37:38 -0000 --001a113d1ceea911450548308dfb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Spencer, There is some expertise overlap, but there are several distinct skills needed especially in the context of virtual network functions since it needs a deep understanding of server/NIC architectures. Thanks, Ramki On Fri, Feb 10, 2017 at 9:19 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Ram, > > On Feb 10, 2017 11:09, "Ram Krishnan" wrote: > > Very good discussion. > > Another aspect to note is that we see value for in-situ OAM for monitorin= g > network functions (especially virtual) besides network interconnects. Thi= s > is captured in Section 3 in the draft (https://datatracker.ietf.org/ > doc/draft-krishnan-opsawg-in-band-pro-sla/?include_text=3D1). > > I believe IPPM charter addresses only network monitoring. > > > The responsible AD for IPPM happens to agree :-) > > Is the expertise required for path monitoring the same as the expertise > required for network element monitoring? > > Thanks, > > Spencer > > > Thanks, > Ramki > > On Fri, Feb 10, 2017 at 7:11 AM, Mirja Kuehlewind (IETF) < > ietf@kuehlewind.net> wrote: > >> Hi Frank, hi all, >> >> please see in-line. >> >> > Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne) < >> fbrockne@cisco.com>: >> > >> > Hi Mirja, >> > >> > you raise an interesting point. The IPPM charter states " Specifying >> network or lower layer OAM mechanisms is out of scope of the IPPM >> charter.", whereas the WG has " Submit a draft on the IPv6 Performance a= nd >> Diagnostic Metrics (PDM) Destination Option as Proposed Standard >> > draft-ietf-ippm-6man-pdm-option" as a milestone. I'd assume that we'd >> likely qualify IPv6 as a transport protocol=E2=80=A6 >> >> If you also cite the sentence before this, this might become clearer: >> >> "The IP Performance Metrics (IPPM) Working Group develops and maintains >> standard metrics that can be applied to the quality, performance, and >> reliability of Internet data delivery services and applications running >> over transport layer protocols (e.g. TCP, UDP) over IP. Specifying netwo= rk >> or lower layer OAM mechanisms is out of scope of the IPPM charter.=E2=80= =9C >> >> It=E2=80=99s focused on performance measurements of data delivery servic= es and >> application, not metric sthat are specific to network operation e.g. >> up-time of a router (as an example that just came to my mind). >> >> So to me the scope and the goals of IPPM and IOAM are overlapping >> currently as for me "real-time telemetry of individual data packets and >> flows=E2=80=9C is exactly what IPPM is doing. >> >> > >> > So far I understood the main focus of the new IOAM WG to be >> network-layer focused, i.e. piggyback OAM-meta-data onto network-layer >> protocols - but that does not necessarily need to be always the case as = you >> implicitly highlight by drawing the link to IPPM. One could also do so >> using e.g. TCP options. I did not read the statement on IPPM in the draf= t >> charter as "not cooperating with IPPM" - I read it in a way that methods >> that do not piggyback information on live traffic are not considered in >> IOAM. That said, especially when it comes to export and interpretation o= f >> in-situ OAM data, there might indeed be common ground between IOAM and I= PPM. >> >> My point is not that there needs to be cooperation. My point is that we >> already have a working group that is mostly charter to do what you want = to >> do. >> >> Mirja >> >> >> > >> > How about we add another sentence to the charter that underlines the >> fact that IOAM would actively seek cooperation with other related effort= s? >> We could add something like: >> > >> > "The IOAM WG seeks cooperation with other appropriate standards bodies >> and forums to promote consistent approaches, as well as definition and >> interpretation of in-situ OAM data." >> > >> > This would naturally capture IETF WGs like IPPM - but also efforts lik= e >> INT in P4, hence we'd even cast the net a little wider. >> > >> > Thoughts? >> > >> > Thanks, Frank >> > >> > -----Original Message----- >> > From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Mirja >> Kuehlewind (IETF) >> > Sent: Freitag, 10. Februar 2017 13:10 >> > To: Carlos Pignataro (cpignata) ; Alvaro Retana >> (aretana) >> > Cc: iesg@ietf.org; The IAB ; Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com>; ioam@ietf.org >> > Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) >> > >> > Hi all, >> > >> > also one more comment on this point: >> > >> >> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata) < >> cpignata@cisco.com>: >> >> >> >>>> Is there any connection with IPPM? >> >> >> >> Yes, there is, as already mentioned above. >> > >> > >> > The charter currently says: >> > >> > "Other ongoing OAM-related efforts in working groups(s) such as MPLS >> and IPPM that do not piggyback information onto the live user data traff= ic >> are out of scope of the IOAM WG.=E2=80=9C >> > >> > which indictates that cooperation with IPPM is not planned. >> > >> > To me in general the relation between this work and other ongoing work >> in the IETF is not very clear and IPPM has several documents and milesto= nes >> that are in scope for this work: >> > >> > - Submit a draft on the IPv6 Performance and Diagnostic Metrics (PDM) >> Destination Option as Proposed Standard: draft-ietf-ippm-6man-pdm-option >> (this draft is mainly done and silenter the publication process soon to = my >> understanding) >> > >> > - Submit an Experimental draft on coloring-based hybrid measurement >> methodologies for loss and delay to the IESG: draft-ietf-ippm-alt-mark-0= 3 >> > >> > I don=E2=80=99t think that the assessment in the charter that IPPM's s= cope does >> not include piggybacked information is correct. Looking at >> draft-brockners-inband-oam-transport-02, I think that any work on IPV6 >> and IPv6 in this scope should be done in IPPM because that=E2=80=99s wer= e this work >> is already on-going and where the measurement expertise is. >> > >> > Mirja >> > >> > >> > >> > >> > _______________________________________________ >> > Ioam mailing list >> > Ioam@ietf.org >> > https://www.ietf.org/mailman/listinfo/ioam >> >> _______________________________________________ >> Ioam mailing list >> Ioam@ietf.org >> https://www.ietf.org/mailman/listinfo/ioam >> > > > > -- > Thanks, > Ramki > > > --=20 Thanks, Ramki --001a113d1ceea911450548308dfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Spencer,

There is some expertise overlap, but= there are several distinct skills needed especially in the context of virt= ual network functions since it needs a deep understanding of server/NIC arc= hitectures.=C2=A0

Thanks,
Ramki

On Fri, Feb 10, 2017 at 9:19 AM, Spencer = Dawkins at IETF <spencerdawkins.ietf@gmail.com> = wrote:
Hi, Ram,

On Feb 10, 2017 = 11:09, "Ram Krishnan" <ramkri123@gmail.com> wrote:
Very good discussion.= =C2=A0
Anothe= r aspect to note is that we see value for in-situ OAM for monitoring networ= k functions (especially virtual) besides network interconnects. This is cap= tured in Section 3 in the draft (https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-= pro-sla/?include_text=3D1).=C2=A0

I believe IPPM charter addresses only network moni= toring.
<= /div>

The responsible AD for IPPM happens to agree :-)

Is the expertise required for path mo= nitoring the same as the expertise required for network element monitoring?=

Thanks,

Spencer


Thanks,
Ramki

On Fri, Feb 10, 2017 at 7:11 AM, Mirja Kuehlewind (IETF) <= ietf@kuehlewind.net> wrote:
Hi Frank, hi all,

please see in-line.

> Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne) <fbrockne@cisco.com>= :
>
> Hi Mirja,
>
> you raise an interesting point. The IPPM charter states=C2=A0 " S= pecifying network or lower layer OAM mechanisms is out of scope of the IPPM= charter.", whereas the WG has " Submit a draft on the IPv6 Perfo= rmance and Diagnostic Metrics (PDM) Destination Option as Proposed Standard=
> draft-ietf-ippm-6man-pdm-option" as a milestone. I'd ass= ume that we'd likely qualify IPv6 as a transport protocol=E2=80=A6

If you also cite the sentence before this, this might become clearer:

"The IP Performance Metrics (IPPM) Working Group develops and maintain= s
standard metrics that can be applied to the quality, performance, and
reliability of Internet data delivery services and applications running
over transport layer protocols (e.g. TCP, UDP) over IP. Specifying network<= br> or lower layer OAM mechanisms is out of scope of the IPPM charter.=E2=80=9C=

It=E2=80=99s focused on performance measurements of data delivery services = and application, not metric sthat are specific to network operation e.g. up= -time of a router (as an example that just came to my mind).

So to me the scope and the goals of IPPM and IOAM are overlapping currently= as for me "real-time telemetry of individual data packets and flows= =E2=80=9C is exactly what IPPM is doing.

>
> So far I understood the main focus of the new IOAM WG to be network-la= yer focused, i.e. piggyback OAM-meta-data onto network-layer protocols - bu= t that does not necessarily need to be always the case as you implicitly hi= ghlight by drawing the link to IPPM. One could also do so using e.g. TCP op= tions. I did not read the statement on IPPM in the draft charter as "n= ot cooperating with IPPM" - I read it in a way that methods that do no= t piggyback information on live traffic are not considered in IOAM. That sa= id, especially when it comes to export and interpretation of in-situ OAM da= ta, there might indeed be common ground between IOAM and IPPM.

My point is not that there needs to be cooperation. My point is that we alr= eady have a working group that is mostly charter to do what you want to do.=

Mirja


>
> How about we add another sentence to the charter that underlines the f= act that IOAM would actively seek cooperation with other related efforts? W= e could add something like:
>
> "The IOAM WG seeks cooperation with other appropriate standards b= odies and forums to promote consistent approaches, as well as definition an= d interpretation of in-situ OAM data."
>
> This would naturally capture IETF WGs like IPPM - but also efforts lik= e INT in P4, hence we'd even cast the net a little wider.
>
> Thoughts?
>
> Thanks, Frank
>
> -----Original Message-----
> From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Mirja Kuehlewind (IETF)
> Sent: Freitag, 10. Februar 2017 13:10
> To: Carlos Pignataro (cpignata) <cpignata@cisco.com>; Alvaro Retana (aretana) &= lt;aretana@cisco.com= >
> Cc: iesg@ietf.org; The IAB <iab@iab.or= g>; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>; = ioam@ietf.org
> Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam)
>
> Hi all,
>
> also one more comment on this point:
>
>> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata) <cpignata@cisco.com= >:
>>
>>>> Is there any connection with IPPM?
>>
>> Yes, there is, as already mentioned above.
>
>
> The charter currently says:
>
> "Other ongoing OAM-related efforts in working groups(s) such as M= PLS and IPPM that do not piggyback information onto the live user data traf= fic are out of scope of the IOAM WG.=E2=80=9C
>
> which indictates that cooperation with IPPM is not planned.
>
> To me in general the relation between this work and other ongoing work= in the IETF is not very clear and IPPM has several documents and milestone= s that are in scope for this work:
>
> - Submit a draft on the IPv6 Performance and Diagnostic Metrics (PDM) = Destination Option as Proposed Standard: draft-ietf-ippm-6man-pdm-option (this draft is mainly done and silenter the publication process soon to = my understanding)
>
> - Submit an Experimental draft on coloring-based hybrid measurement me= thodologies for loss and delay to the IESG: draft-ietf-ippm-alt-mark-03
>
> I don=E2=80=99t think that the assessment in the charter that IPPM'= ;s scope does not include piggybacked information is correct. Looking at dr= aft-brockners-inband-oam-transport-02, I think that any work on IPV6 a= nd IPv6 in this scope should be done in IPPM because that=E2=80=99s were th= is work is already on-going and where the measurement expertise is.
>
> Mirja
>
>
>
>
> _______________________________________________
> Ioam mailing list
> Ioam@ietf.org > https://www.ietf.org/mailman/listinfo/ioam
_______________________________________________
Ioam mailing list
Ioam@ietf.org
https://www.ietf.org/mailman/listinfo/ioam



--
Thanks,= =C2=A0
Ramki




--
Th= anks,=C2=A0
Ramki
--001a113d1ceea911450548308dfb-- From nobody Fri Feb 10 11:34:28 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA4C129B21; Fri, 10 Feb 2017 11:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, 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=joelhalpern.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 m_-Ngwfyz7-S; Fri, 10 Feb 2017 11:34:21 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 773E6129AF2; Fri, 10 Feb 2017 11:34:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4AE87240FAB; Fri, 10 Feb 2017 11:34:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486755261; bh=NnmOqSpTuMzTweiK+3T+4vE1R5ri5foJPCYSso/z5LY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Tl9G5KTHiQW6tED4uunG0xYEj+Y/vQCeE5RyyF7V1mMg01Gx72P0Uq32Uun0A2dKS 5XBMV+EnLF0xrQ9Z2ZdcU++HqdPRa9h8rZUj3/VD+8sHEusYnQmu2Y3Il7UWWJQUGx dUb4retfJpFjmyTdAhC5ugztmCu4dqQidb1Khzgk= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 2532024099F; Fri, 10 Feb 2017 11:34:20 -0800 (PST) To: Ram Krishnan , "Mirja Kuehlewind (IETF)" References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> <0bdcfd0be2c84ffa81b1658af60f084d@XCH-RCD-008.cisco.com> <9826D9EC-E161-48A6-AC5B-EA0C73BFE526@kuehlewind.net> From: "Joel M. Halpern" Message-ID: <49ef4609-0bce-4cfe-98c2-46376de9f1df@joelhalpern.com> Date: Fri, 10 Feb 2017 14:34:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "Frank Brockners \(fbrockne\)" , The IAB , "iesg@ietf.org" , "ioam@ietf.org" , "Alvaro Retana \(aretana\)" , Spencer Dawkins at IETF Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 19:34:23 -0000 I would be very careful about using this proposal as a justification for an iOAM working group. it is SFC specific. And there are some interesting challenges in the details. Yours, Joel On 2/10/17 12:09 PM, Ram Krishnan wrote: > Very good discussion. > > Another aspect to note is that we see value for in-situ OAM for > monitoring network functions (especially virtual) besides network > interconnects. This is captured in Section 3 in the draft > (https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro-sla/?include_text=1). > > I believe IPPM charter addresses only network monitoring. > > Thanks, > Ramki > > On Fri, Feb 10, 2017 at 7:11 AM, Mirja Kuehlewind (IETF) > > wrote: > > Hi Frank, hi all, > > please see in-line. > > > Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne) > >: > > > > Hi Mirja, > > > > you raise an interesting point. The IPPM charter states " > Specifying network or lower layer OAM mechanisms is out of scope of > the IPPM charter.", whereas the WG has " Submit a draft on the IPv6 > Performance and Diagnostic Metrics (PDM) Destination Option as > Proposed Standard > > draft-ietf-ippm-6man-pdm-option" as a milestone. I'd assume that > we'd likely qualify IPv6 as a transport protocol > > If you also cite the sentence before this, this might become clearer: > > "The IP Performance Metrics (IPPM) Working Group develops and maintains > standard metrics that can be applied to the quality, performance, and > reliability of Internet data delivery services and applications running > over transport layer protocols (e.g. TCP, UDP) over IP. Specifying > network > or lower layer OAM mechanisms is out of scope of the IPPM charter. > > Its focused on performance measurements of data delivery services > and application, not metric sthat are specific to network operation > e.g. up-time of a router (as an example that just came to my mind). > > So to me the scope and the goals of IPPM and IOAM are overlapping > currently as for me "real-time telemetry of individual data packets > and flows is exactly what IPPM is doing. > > > > > So far I understood the main focus of the new IOAM WG to be > network-layer focused, i.e. piggyback OAM-meta-data onto > network-layer protocols - but that does not necessarily need to be > always the case as you implicitly highlight by drawing the link to > IPPM. One could also do so using e.g. TCP options. I did not read > the statement on IPPM in the draft charter as "not cooperating with > IPPM" - I read it in a way that methods that do not piggyback > information on live traffic are not considered in IOAM. That said, > especially when it comes to export and interpretation of in-situ OAM > data, there might indeed be common ground between IOAM and IPPM. > > My point is not that there needs to be cooperation. My point is that > we already have a working group that is mostly charter to do what > you want to do. > > Mirja > > > > > > How about we add another sentence to the charter that underlines > the fact that IOAM would actively seek cooperation with other > related efforts? We could add something like: > > > > "The IOAM WG seeks cooperation with other appropriate standards > bodies and forums to promote consistent approaches, as well as > definition and interpretation of in-situ OAM data." > > > > This would naturally capture IETF WGs like IPPM - but also efforts > like INT in P4, hence we'd even cast the net a little wider. > > > > Thoughts? > > > > Thanks, Frank > > > > -----Original Message----- > > From: Ioam [mailto:ioam-bounces@ietf.org > ] On Behalf Of Mirja Kuehlewind (IETF) > > Sent: Freitag, 10. Februar 2017 13:10 > > To: Carlos Pignataro (cpignata) >; Alvaro Retana (aretana) > > > > Cc: iesg@ietf.org ; The IAB >; Spencer Dawkins at IETF > >; ioam@ietf.org > > > Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) > > > > Hi all, > > > > also one more comment on this point: > > > >> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata) > >: > >> > >>>> Is there any connection with IPPM? > >> > >> Yes, there is, as already mentioned above. > > > > > > The charter currently says: > > > > "Other ongoing OAM-related efforts in working groups(s) such as > MPLS and IPPM that do not piggyback information onto the live user > data traffic are out of scope of the IOAM WG. > > > > which indictates that cooperation with IPPM is not planned. > > > > To me in general the relation between this work and other ongoing > work in the IETF is not very clear and IPPM has several documents > and milestones that are in scope for this work: > > > > - Submit a draft on the IPv6 Performance and Diagnostic Metrics > (PDM) Destination Option as Proposed Standard: > draft-ietf-ippm-6man-pdm-option (this draft is mainly done and > silenter the publication process soon to my understanding) > > > > - Submit an Experimental draft on coloring-based hybrid > measurement methodologies for loss and delay to the IESG: > draft-ietf-ippm-alt-mark-03 > > > > I dont think that the assessment in the charter that IPPM's scope > does not include piggybacked information is correct. Looking at > draft-brockners-inband-oam-transport-02, I think that any work on > IPV6 and IPv6 in this scope should be done in IPPM because thats > were this work is already on-going and where the measurement > expertise is. > > > > Mirja > > > > > > > > > > _______________________________________________ > > Ioam mailing list > > Ioam@ietf.org > > https://www.ietf.org/mailman/listinfo/ioam > > > _______________________________________________ > Ioam mailing list > Ioam@ietf.org > https://www.ietf.org/mailman/listinfo/ioam > > > > > > -- > Thanks, > Ramki > > > _______________________________________________ > Ioam mailing list > Ioam@ietf.org > https://www.ietf.org/mailman/listinfo/ioam > From nobody Fri Feb 10 12:33:00 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1E8129BB4; Fri, 10 Feb 2017 12:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 TVgIB8YV2gJm; Fri, 10 Feb 2017 12:32:53 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A562129BB3; Fri, 10 Feb 2017 12:32:53 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1AKWpJ9013876; Fri, 10 Feb 2017 20:32:51 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1AKWhir013809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2017 20:32:49 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> <0bdcfd0be2c84ffa81b1658af60f084d@XCH-RCD-008.cisco.com> <9826D9EC-E161-48A6-AC5B-EA0C73BFE526@kuehlewind.net> <49ef4609-0bce-4cfe-98c2-46376de9f1df@joelhalpern.com> In-Reply-To: Date: Fri, 10 Feb 2017 20:32:42 -0000 Message-ID: <0cd801d283dc$d9020e00$8b062a00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPa9VlOQLpUKVlo/4ITVNuqPkWhALz7hP3Abnb0PkCgVoGawITALvDApfLV6ACApF05wKZwB35AZARn52g2KFJcIAADceA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22878.002 X-TM-AS-Result: No--7.472-10.0-31-10 X-imss-scan-details: No--7.472-10.0-31-10 X-TMASE-MatchedRID: 7ySqCuYCpfgXwe9fvTutcyZm6wdY+F8KE3NxsGztrMtrEoFtNYg0CwaN 5lIAb71zUi3e3BXWmF/DOJYWUVJEC6f0QmPqa4kezNY33yIEF4Zp0hj6DPLcL5wsUqEjZnPr0u5 faGP8ztQ6TvcoucMVb9kVAVb359lcaXCfGZQxX8WeAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0 ePs7A07b4iOwQQ4jNib5ID7a3N+gIQxZ7LO9UO+8Hu0kKDpjJwSI+5gnFoZ3M= Archived-At: Cc: 'The IAB' , iesg@ietf.org, ioam@ietf.org Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:32:58 -0000 Well, indeed. This is why I was scratching away at whether this is a proposal for a generic OAM encapsulation. AFAICS the devil is in the detail of the encapsulation/forwarding/switching mechanism and a lot of the information that has to be encoded will be different. So, will this proposal lead to more than a set of TLVs that would be filled out for different use cases? It *might* be that it would be more useful to identify the target us cases (i.., those that people want to build and deploy now) and work on those. Adrian > -----Original Message----- > From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 10 February 2017 19:34 > To: Ram Krishnan; Mirja Kuehlewind (IETF) > Cc: Carlos Pignataro (cpignata); Frank Brockners (fbrockne); The IAB; > iesg@ietf.org; ioam@ietf.org; Alvaro Retana (aretana); Spencer Dawkins at IETF > Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) > > I would be very careful about using this proposal as a justification for > an iOAM working group. > it is SFC specific. > And there are some interesting challenges in the details. > > Yours, > Joel From nobody Fri Feb 10 14:12:07 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBD7129C92; Fri, 10 Feb 2017 14:12:02 -0800 (PST) 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=unavailable 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 sN0JTj6aFPD4; Fri, 10 Feb 2017 14:12:01 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8A6129C81; Fri, 10 Feb 2017 14:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1158; q=dns/txt; s=iport; t=1486764721; x=1487974321; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3T4oPjLX1BcsO7MOJ62hhAZNqNko2roRymIb92KG8Ac=; b=TVMbyd6gAxSzVjmrTkKr2C2CfRHN/eDknPZgS4BRFH5LfmcfQL50UWrv LDluIWZ4qUi5Qgws/zbr0khxoYuAPM3z5BJjTFlVR6rPIft5HR6KmCS9C /itKy9m1B3/zHUVwbgfGSSdCG1KA6I02fIebOnsSOOK4qgIVcXiyK1jN9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AQDPOZ5Y/5tdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1KBageDUooIkg6IDI0qgg2GIgIagmE/GAECAQEBAQEBAWIohGk?= =?us-ascii?q?BAQEDASMRRQULAgEIGAICJgICAh8RFRACBA4FiWADDQiwK4Ilhy0NhBMBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgQuFQYIFgmqCUYUJLoIxAQSIfoxWhWQ6AY16hBm?= =?us-ascii?q?RBYhLgWqIXwEfOH5PFU0BhjB1iRKBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,142,1484006400"; d="scan'208";a="179262091" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2017 22:12:00 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v1AMBx54016393 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 22:12:00 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Feb 2017 17:11:59 -0500 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; Fri, 10 Feb 2017 17:11:58 -0500 From: "Carlos Pignataro (cpignata)" To: Spencer Dawkins at IETF Thread-Topic: [Ioam] Internal WG Review: In-situ OAM (ioam) Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFf5E4AgAECTQCAAFm/gIABjSIAgABXRgA= Date: Fri, 10 Feb 2017 22:11:58 +0000 Message-ID: <59F25558-51E2-4F21-BAB7-3BD52CD966B9@cisco.com> References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> 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.82.168.40] Content-Type: text/plain; charset="utf-8" Content-ID: <237B407DA8035E4EA716F24AB33389A1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Alvaro Retana \(aretana\)" , "iab@iab.org" , "iesg@ietf.org" , "ioam@ietf.org" Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 22:12:03 -0000 U3BlbmNlciwNCg0KQSBjb3VwbGUgb2YgcXVpY2sgZm9sbG93LXVwczoNCg0KPiBPbiBGZWIgMTAs IDIwMTcsIGF0IDExOjU5IEFNLCBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiA8c3BlbmNlcmRhd2tp bnMuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSSBhbSBub3Qgc3VyZSB0aGVyZSBpcyBh IHN0cm9uZyBjb25uZWN0aW9uIHRvIFRTVldHIOKAlCBidXQgb24gdGhlIG90aGVyIGhhbmQsIGl0 IG1pZ2h0IG5vdCBodXJ0IHRvIGNhbGwgaXQgb3V0Lg0KPiANCj4gSSB3YXMgYWN0dWFsbHkgdGhp bmtpbmcgYWJvdXQgb3RoZXIgcmVhc29ucyB0byBpbmNsdWRlIFRTVldHLCBidXQganVzdCB0byBj b3ZlciBvbmUgcXVlc3Rpb24gLSBJJ20gYXNzdW1pbmcgdGhhdCBhZGRpbmcgSU9BTSBhdHRyaWJ1 dGVzIHRvIGEgdXNlciBkYXRhIHBhY2tldCB3aWxsIGluY3JlYXNlIHRoZSBNVFUgc2l6ZS4gSWYg dGhhdCdzIHRydWUsIHRoYXQgcG9pbnQgYWxvbmUgd291bGQgbWFrZSBUU1ZXRyBhd2FyZW5lc3Mg d29ydGggY2FsbGluZyBvdXQuDQo+IA0KDQpJbmRlZWQuDQoNCj4gPj4gSXMgdGhlcmUgYW55IGNv bm5lY3Rpb24gd2l0aCBJUFBNPw0KPiANCj4gWWVzLCB0aGVyZSBpcywgYXMgYWxyZWFkeSBtZW50 aW9uZWQgYWJvdmUuDQo+IA0KPiBJIHNlZSB0aGF0IHRoaXMgbGlua2FnZSBpcyB1bmRlciBkaXNj dXNzaW9uIGZ1cnRoZXIgZG93biwgc28gSSdsbCBjb21tZW50IHRoZXJlIGlmIEkgaGF2ZSBzb21l dGhpbmcgdG8gY29udHJpYnV0ZS4NCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHNwZWVkeSByZXNwb25z ZSENCg0KVGhhbmsgeW91IQ0KDQo+IA0KPiBTcGVuY2VyDQo+IA0KDQpDYXJsb3Mu From nobody Fri Feb 10 22:10:39 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288D4129B5A for ; Fri, 10 Feb 2017 12:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 MA8eEvnSlNYA for ; Fri, 10 Feb 2017 12:02:36 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E5C129B5F for ; Fri, 10 Feb 2017 12:02:30 -0800 (PST) Received: (qmail 19931 invoked from network); 10 Feb 2017 21:02:28 +0100 Received: from p5dec2a07.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.42.7) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 10 Feb 2017 21:02:28 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <0cca01d283d6$7aac2df0$700489d0$@juniper.net> Date: Fri, 10 Feb 2017 21:02:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> <0bdcfd0be2c84ffa81b1658af60f084d@XCH-RCD-008.cisco.com> <9826D9EC-E161-48A6-AC5B-EA0C73BFE526@kuehlewind.net> <49ef4609-0bce-4cfe-98c2-46376de9f1df@joelhalpern.com> <0cca01d283d6$7aac2df0$700489d0$@juniper.net> To: afarrel@juniper.net, Ram Krishnan X-Mailer: Apple Mail (2.3259) Archived-At: X-Mailman-Approved-At: Fri, 10 Feb 2017 22:10:38 -0800 Cc: "Carlos Pignataro \(cpignata\)" , "Frank Brockners \(fbrockne\)" , ioam@ietf.org, The IESG , "Alvaro Retana \(aretana\)" , "Joel M. Halpern" , The IAB , Spencer Dawkins at IETF Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:02:38 -0000 Hi Ram, to me the current charter seem to not include monitoring of network = functions. Also your draft is currently not listed as related on the BoF = page. I had a very brief look at this now and I don=E2=80=99t think that = Data-plane probe for in-band telemetry collection = (draft-lapukhov-dataplane-probe) and Network Service Header KPI Stamping = (draft-browne-sfc-nsh-kpi-stamp), which are both listed as use cases, = can or should be treated the same. As Joel notes below SFC is a specific = use case and probably requires very different expertise. I don=E2=80=99t = think throwing everything the same working group is the right approach = here. Mirja > Am 10.02.2017 um 20:47 schrieb Adrian Farrel : >=20 > Well, indeed. >=20 > This is why I was scratching away at whether this is a proposal for a = generic > OAM encapsulation. >=20 > AFAICS the devil is in the detail of the = encapsulation/forwarding/switching > mechanism and a lot of the information that has to be encoded will be = different. > So, will this proposal lead to more than a set of TLVs that would be = filled out > for different use cases? >=20 > It *might* be that it would be more useful to identify the target us = cases (i.., > those that people want to build and deploy now) and work on those. >=20 > Adrian >=20 >> -----Original Message----- >> From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Joel M. = Halpern >> Sent: 10 February 2017 19:34 >> To: Ram Krishnan; Mirja Kuehlewind (IETF) >> Cc: Carlos Pignataro (cpignata); Frank Brockners (fbrockne); The IAB; >> iesg@ietf.org; ioam@ietf.org; Alvaro Retana (aretana); Spencer = Dawkins at IETF >> Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) >>=20 >> I would be very careful about using this proposal as a justification = for >> an iOAM working group. >> it is SFC specific. >> And there are some interesting challenges in the details. >>=20 >> Yours, >> Joel >>=20 >> On 2/10/17 12:09 PM, Ram Krishnan wrote: >>> Very good discussion. >>>=20 >>> Another aspect to note is that we see value for in-situ OAM for >>> monitoring network functions (especially virtual) besides network >>> interconnects. This is captured in Section 3 in the draft >>> (https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro- >> sla/?include_text=3D1). >>>=20 >>> I believe IPPM charter addresses only network monitoring. >>>=20 >>> Thanks, >>> Ramki >>>=20 >>> On Fri, Feb 10, 2017 at 7:11 AM, Mirja Kuehlewind (IETF) >>> > wrote: >>>=20 >>> Hi Frank, hi all, >>>=20 >>> please see in-line. >>>=20 >>>> Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne) >>> >: >>>>=20 >>>> Hi Mirja, >>>>=20 >>>> you raise an interesting point. The IPPM charter states " >>> Specifying network or lower layer OAM mechanisms is out of scope = of >>> the IPPM charter.", whereas the WG has " Submit a draft on the = IPv6 >>> Performance and Diagnostic Metrics (PDM) Destination Option as >>> Proposed Standard >>>> draft-ietf-ippm-6man-pdm-option" as a milestone. I'd assume that >>> we'd likely qualify IPv6 as a transport protocol. >>>=20 >>> If you also cite the sentence before this, this might become = clearer: >>>=20 >>> "The IP Performance Metrics (IPPM) Working Group develops and = maintains >>> standard metrics that can be applied to the quality, performance, = and >>> reliability of Internet data delivery services and applications = running >>> over transport layer protocols (e.g. TCP, UDP) over IP. = Specifying >>> network >>> or lower layer OAM mechanisms is out of scope of the IPPM = charter." >>>=20 >>> It's focused on performance measurements of data delivery = services >>> and application, not metric sthat are specific to network = operation >>> e.g. up-time of a router (as an example that just came to my = mind). >>>=20 >>> So to me the scope and the goals of IPPM and IOAM are overlapping >>> currently as for me "real-time telemetry of individual data = packets >>> and flows" is exactly what IPPM is doing. >>>=20 >>>>=20 >>>> So far I understood the main focus of the new IOAM WG to be >>> network-layer focused, i.e. piggyback OAM-meta-data onto >>> network-layer protocols - but that does not necessarily need to = be >>> always the case as you implicitly highlight by drawing the link = to >>> IPPM. One could also do so using e.g. TCP options. I did not read >>> the statement on IPPM in the draft charter as "not cooperating = with >>> IPPM" - I read it in a way that methods that do not piggyback >>> information on live traffic are not considered in IOAM. That = said, >>> especially when it comes to export and interpretation of in-situ = OAM >>> data, there might indeed be common ground between IOAM and IPPM. >>>=20 >>> My point is not that there needs to be cooperation. My point is = that >>> we already have a working group that is mostly charter to do what >>> you want to do. >>>=20 >>> Mirja >>>=20 >>>=20 >>>>=20 >>>> How about we add another sentence to the charter that underlines >>> the fact that IOAM would actively seek cooperation with other >>> related efforts? We could add something like: >>>>=20 >>>> "The IOAM WG seeks cooperation with other appropriate standards >>> bodies and forums to promote consistent approaches, as well as >>> definition and interpretation of in-situ OAM data." >>>>=20 >>>> This would naturally capture IETF WGs like IPPM - but also efforts >>> like INT in P4, hence we'd even cast the net a little wider. >>>>=20 >>>> Thoughts? >>>>=20 >>>> Thanks, Frank >>>>=20 >>>> -----Original Message----- >>>> From: Ioam [mailto:ioam-bounces@ietf.org >>> ] On Behalf Of Mirja Kuehlewind = (IETF) >>>> Sent: Freitag, 10. Februar 2017 13:10 >>>> To: Carlos Pignataro (cpignata) >> >; Alvaro Retana (aretana) >>> > >>>> Cc: iesg@ietf.org ; The IAB >> >; Spencer Dawkins at IETF >>> >> >; ioam@ietf.org >>> >>>> Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) >>>>=20 >>>> Hi all, >>>>=20 >>>> also one more comment on this point: >>>>=20 >>>>> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata) >>> >: >>>>>=20 >>>>>>> Is there any connection with IPPM? >>>>>=20 >>>>> Yes, there is, as already mentioned above. >>>>=20 >>>>=20 >>>> The charter currently says: >>>>=20 >>>> "Other ongoing OAM-related efforts in working groups(s) such as >>> MPLS and IPPM that do not piggyback information onto the live = user >>> data traffic are out of scope of the IOAM WG." >>>>=20 >>>> which indictates that cooperation with IPPM is not planned. >>>>=20 >>>> To me in general the relation between this work and other ongoing >>> work in the IETF is not very clear and IPPM has several documents >>> and milestones that are in scope for this work: >>>>=20 >>>> - Submit a draft on the IPv6 Performance and Diagnostic Metrics >>> (PDM) Destination Option as Proposed Standard: >>> draft-ietf-ippm-6man-pdm-option (this draft is mainly done and >>> silenter the publication process soon to my understanding) >>>>=20 >>>> - Submit an Experimental draft on coloring-based hybrid >>> measurement methodologies for loss and delay to the IESG: >>> draft-ietf-ippm-alt-mark-03 >>>>=20 >>>> I don't think that the assessment in the charter that IPPM's scope >>> does not include piggybacked information is correct. Looking at >>> draft-brockners-inband-oam-transport-02, I think that any work on >>> IPV6 and IPv6 in this scope should be done in IPPM because that's >>> were this work is already on-going and where the measurement >>> expertise is. >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ioam mailing list >>>> Ioam@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ioam >>> >>>=20 >>> _______________________________________________ >>> Ioam mailing list >>> Ioam@ietf.org >>> https://www.ietf.org/mailman/listinfo/ioam >>> >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Thanks, >>> Ramki >>>=20 >>>=20 >>> _______________________________________________ >>> Ioam mailing list >>> Ioam@ietf.org >>> https://www.ietf.org/mailman/listinfo/ioam >>>=20 >>=20 >> _______________________________________________ >> Ioam mailing list >> Ioam@ietf.org >> https://www.ietf.org/mailman/listinfo/ioam >=20 From nobody Fri Feb 10 22:10:42 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F148B129B6E; Fri, 10 Feb 2017 12:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 SHCW_d3FuWB9; Fri, 10 Feb 2017 12:12:07 -0800 (PST) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 4211A129B6A; Fri, 10 Feb 2017 12:12:05 -0800 (PST) Received: by mail-oi0-x241.google.com with SMTP id x84so3254149oix.2; Fri, 10 Feb 2017 12:12:05 -0800 (PST) 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=imdKT+8ScC59n5pZlZfld/HbnvuZhnw4r9P5JAqojz8=; b=Y0VGN0hwiXps+rHrHWB1fqEBTWiCdnDBfO6LCtSnkz6HpiBAfsTeKOT8wYFCo8td+I Xb/vdOVJV7vjrqvMdIAsMa6+ZF593WiP2z4ljJwdvb4gvtCkpx/ACPgGODMyg8Jgzlcf bb4YjZ3MWxSDOZzA9r+r6nHQGOVlRaeYSQBArYZcG+HcivjESADhFjkKCMNHKa5l7iVG V/IbWvLi/HARmkj2VIFfO1OihRFamdq5xRuyMfTbFTx1GALZ5YagKG8UcnIdH8JkhzGa S/WzskfbXgtmEFyRe4GpncZThtYwk9/P8VskEHS6mCCf/bIB83/wkN/BlD8cDXy2i0Fz Rsqw== 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=imdKT+8ScC59n5pZlZfld/HbnvuZhnw4r9P5JAqojz8=; b=TT0su5sMfwBBk4O9X/iDMwth7bvvts3xWpTd+kLuaK9pNAmMZBlDkc4amCFd/UGcP0 BYaW9UZzW05a3UtVbvfP9pWSGFvTYl8ClF4YDjpuqWwvrL+EjaWvZRhPBDCtyx+/oZkT QxXCp7Zk6P77MiHNnccRZ584WXyUOXhg6Ch6BACDWSt9L24Vsg0sRBFadI0Zp+WSiWRJ idi0B8bp1Nz88UVZBJ0pkPzDZE5hHmsv2uQghk/2KEd8PPbJnUeG5nkur+0E6SjCvvDV UvA/n+wND8WX2EYua0yuj6BD8+9Jg7bY/UPE/Q2aBgpzn46uedsVAG2O/QhzlB36+0kI xavQ== X-Gm-Message-State: AMke39lNRqoA5PYQkIA/Sx+YBrcUonzCj+1ycaH1pgJoBQDk/wcHUvD2FBdBukPgHpBwXTHcdccWOmNZuDHkqQ== X-Received: by 10.202.8.197 with SMTP id 188mr5939442oii.22.1486757524533; Fri, 10 Feb 2017 12:12:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.1 with HTTP; Fri, 10 Feb 2017 12:12:04 -0800 (PST) In-Reply-To: References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <58201ECE-F536-4ADC-98DE-95BCDAC28D31@kuehlewind.net> <0bdcfd0be2c84ffa81b1658af60f084d@XCH-RCD-008.cisco.com> <9826D9EC-E161-48A6-AC5B-EA0C73BFE526@kuehlewind.net> <49ef4609-0bce-4cfe-98c2-46376de9f1df@joelhalpern.com> <0cca01d283d6$7aac2df0$700489d0$@juniper.net> From: Ram Krishnan Date: Fri, 10 Feb 2017 12:12:04 -0800 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary=94eb2c1305721dfa2c054832b64d Archived-At: X-Mailman-Approved-At: Fri, 10 Feb 2017 22:10:38 -0800 Cc: "Carlos Pignataro \(cpignata\)" , "Frank Brockners \(fbrockne\)" , afarrel@juniper.net, The IAB , The IESG , ioam@ietf.org, "Alvaro Retana \(aretana\)" , "Joel M. Halpern" , Spencer Dawkins at IETF Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:12:10 -0000 --94eb2c1305721dfa2c054832b64d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mirja, Fair points. Still wondering how my draft missed the BoF page - I will get it added through the BoF coordinators. Thanks, Ramki On Fri, Feb 10, 2017 at 12:02 PM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi Ram, > > to me the current charter seem to not include monitoring of network > functions. Also your draft is currently not listed as related on the BoF > page. I had a very brief look at this now and I don=E2=80=99t think that = Data-plane > probe for in-band telemetry collection (draft-lapukhov-dataplane-probe) > and Network Service Header KPI Stamping (draft-browne-sfc-nsh-kpi-stamp), > which are both listed as use cases, can or should be treated the same. As > Joel notes below SFC is a specific use case and probably requires very > different expertise. I don=E2=80=99t think throwing everything the same w= orking > group is the right approach here. > > Mirja > > > > Am 10.02.2017 um 20:47 schrieb Adrian Farrel : > > > > Well, indeed. > > > > This is why I was scratching away at whether this is a proposal for a > generic > > OAM encapsulation. > > > > AFAICS the devil is in the detail of the encapsulation/forwarding/ > switching > > mechanism and a lot of the information that has to be encoded will be > different. > > So, will this proposal lead to more than a set of TLVs that would be > filled out > > for different use cases? > > > > It *might* be that it would be more useful to identify the target us > cases (i.., > > those that people want to build and deploy now) and work on those. > > > > Adrian > > > >> -----Original Message----- > >> From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Joel M. Halpern > >> Sent: 10 February 2017 19:34 > >> To: Ram Krishnan; Mirja Kuehlewind (IETF) > >> Cc: Carlos Pignataro (cpignata); Frank Brockners (fbrockne); The IAB; > >> iesg@ietf.org; ioam@ietf.org; Alvaro Retana (aretana); Spencer Dawkins > at IETF > >> Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) > >> > >> I would be very careful about using this proposal as a justification f= or > >> an iOAM working group. > >> it is SFC specific. > >> And there are some interesting challenges in the details. > >> > >> Yours, > >> Joel > >> > >> On 2/10/17 12:09 PM, Ram Krishnan wrote: > >>> Very good discussion. > >>> > >>> Another aspect to note is that we see value for in-situ OAM for > >>> monitoring network functions (especially virtual) besides network > >>> interconnects. This is captured in Section 3 in the draft > >>> (https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro- > >> sla/?include_text=3D1). > >>> > >>> I believe IPPM charter addresses only network monitoring. > >>> > >>> Thanks, > >>> Ramki > >>> > >>> On Fri, Feb 10, 2017 at 7:11 AM, Mirja Kuehlewind (IETF) > >>> > wrote: > >>> > >>> Hi Frank, hi all, > >>> > >>> please see in-line. > >>> > >>>> Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne) > >>> >: > >>>> > >>>> Hi Mirja, > >>>> > >>>> you raise an interesting point. The IPPM charter states " > >>> Specifying network or lower layer OAM mechanisms is out of scope o= f > >>> the IPPM charter.", whereas the WG has " Submit a draft on the IPv= 6 > >>> Performance and Diagnostic Metrics (PDM) Destination Option as > >>> Proposed Standard > >>>> draft-ietf-ippm-6man-pdm-option" as a milestone. I'd assume that > >>> we'd likely qualify IPv6 as a transport protocol. > >>> > >>> If you also cite the sentence before this, this might become > clearer: > >>> > >>> "The IP Performance Metrics (IPPM) Working Group develops and > maintains > >>> standard metrics that can be applied to the quality, performance, > and > >>> reliability of Internet data delivery services and applications > running > >>> over transport layer protocols (e.g. TCP, UDP) over IP. Specifying > >>> network > >>> or lower layer OAM mechanisms is out of scope of the IPPM charter.= " > >>> > >>> It's focused on performance measurements of data delivery services > >>> and application, not metric sthat are specific to network operatio= n > >>> e.g. up-time of a router (as an example that just came to my mind)= . > >>> > >>> So to me the scope and the goals of IPPM and IOAM are overlapping > >>> currently as for me "real-time telemetry of individual data packet= s > >>> and flows" is exactly what IPPM is doing. > >>> > >>>> > >>>> So far I understood the main focus of the new IOAM WG to be > >>> network-layer focused, i.e. piggyback OAM-meta-data onto > >>> network-layer protocols - but that does not necessarily need to be > >>> always the case as you implicitly highlight by drawing the link to > >>> IPPM. One could also do so using e.g. TCP options. I did not read > >>> the statement on IPPM in the draft charter as "not cooperating wit= h > >>> IPPM" - I read it in a way that methods that do not piggyback > >>> information on live traffic are not considered in IOAM. That said, > >>> especially when it comes to export and interpretation of in-situ O= AM > >>> data, there might indeed be common ground between IOAM and IPPM. > >>> > >>> My point is not that there needs to be cooperation. My point is th= at > >>> we already have a working group that is mostly charter to do what > >>> you want to do. > >>> > >>> Mirja > >>> > >>> > >>>> > >>>> How about we add another sentence to the charter that underlines > >>> the fact that IOAM would actively seek cooperation with other > >>> related efforts? We could add something like: > >>>> > >>>> "The IOAM WG seeks cooperation with other appropriate standards > >>> bodies and forums to promote consistent approaches, as well as > >>> definition and interpretation of in-situ OAM data." > >>>> > >>>> This would naturally capture IETF WGs like IPPM - but also efforts > >>> like INT in P4, hence we'd even cast the net a little wider. > >>>> > >>>> Thoughts? > >>>> > >>>> Thanks, Frank > >>>> > >>>> -----Original Message----- > >>>> From: Ioam [mailto:ioam-bounces@ietf.org > >>> ] On Behalf Of Mirja Kuehlewind > (IETF) > >>>> Sent: Freitag, 10. Februar 2017 13:10 > >>>> To: Carlos Pignataro (cpignata) >>> >; Alvaro Retana (aretana) > >>> > > >>>> Cc: iesg@ietf.org ; The IAB >>> >; Spencer Dawkins at IETF > >>> >>> >; ioam@ietf.org > >>> > >>>> Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) > >>>> > >>>> Hi all, > >>>> > >>>> also one more comment on this point: > >>>> > >>>>> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata) > >>> >: > >>>>> > >>>>>>> Is there any connection with IPPM? > >>>>> > >>>>> Yes, there is, as already mentioned above. > >>>> > >>>> > >>>> The charter currently says: > >>>> > >>>> "Other ongoing OAM-related efforts in working groups(s) such as > >>> MPLS and IPPM that do not piggyback information onto the live user > >>> data traffic are out of scope of the IOAM WG." > >>>> > >>>> which indictates that cooperation with IPPM is not planned. > >>>> > >>>> To me in general the relation between this work and other ongoing > >>> work in the IETF is not very clear and IPPM has several documents > >>> and milestones that are in scope for this work: > >>>> > >>>> - Submit a draft on the IPv6 Performance and Diagnostic Metrics > >>> (PDM) Destination Option as Proposed Standard: > >>> draft-ietf-ippm-6man-pdm-option (this draft is mainly done and > >>> silenter the publication process soon to my understanding) > >>>> > >>>> - Submit an Experimental draft on coloring-based hybrid > >>> measurement methodologies for loss and delay to the IESG: > >>> draft-ietf-ippm-alt-mark-03 > >>>> > >>>> I don't think that the assessment in the charter that IPPM's scope > >>> does not include piggybacked information is correct. Looking at > >>> draft-brockners-inband-oam-transport-02, I think that any work on > >>> IPV6 and IPv6 in this scope should be done in IPPM because that's > >>> were this work is already on-going and where the measurement > >>> expertise is. > >>>> > >>>> Mirja > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Ioam mailing list > >>>> Ioam@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ioam > >>> > >>> > >>> _______________________________________________ > >>> Ioam mailing list > >>> Ioam@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ioam > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Thanks, > >>> Ramki > >>> > >>> > >>> _______________________________________________ > >>> Ioam mailing list > >>> Ioam@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ioam > >>> > >> > >> _______________________________________________ > >> Ioam mailing list > >> Ioam@ietf.org > >> https://www.ietf.org/mailman/listinfo/ioam > > > > --=20 Thanks, Ramki --94eb2c1305721dfa2c054832b64d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja,

Fair points. Still wondering how my dra= ft missed the BoF page - I will get it added through the BoF coordinators.<= /div>

Thanks,
Ramki

On Fri, Feb 10, 2017 at 12:02 PM, Mirja Kuehlewind (IETF) = <ietf@kuehlewind.net> wrote:
Hi Ram,

to me the current charter seem to not include monitoring of network functio= ns. Also your draft is currently not listed as related on the BoF page. I h= ad a very brief look at this now and I don=E2=80=99t think that Data-plane = probe for in-band telemetry collection (draft-lapukhov-dataplane-probe= ) and Network Service Header KPI Stamping (draft-browne-sfc-nsh-kpi-st= amp), which are both listed as use cases, can or should be treated the same= . As Joel notes below SFC is a specific use case and probably requires very= different expertise. I don=E2=80=99t think throwing everything the same wo= rking group is the right approach here.

Mirja


> Am 10.02.2017 um 20:47 schrieb Adrian Farrel <afarrel@juniper.net>:
>
> Well, indeed.
>
> This is why I was scratching away at whether this is a proposal for a = generic
> OAM encapsulation.
>
> AFAICS the devil is in the detail of the encapsulation/forwarding/switching
> mechanism and a lot of the information that has to be encoded will be = different.
> So, will this proposal lead to more than a set of TLVs that would be f= illed out
> for different use cases?
>
> It *might* be that it would be more useful to identify the target us c= ases (i..,
> those that people want to build and deploy now) and work on those.
>
> Adrian
>
>> -----Original Message-----
>> From: Ioam [mailto:ioam-b= ounces@ietf.org] On Behalf Of Joel M. Halpern
>> Sent: 10 February 2017 19:34
>> To: Ram Krishnan; Mirja Kuehlewind (IETF)
>> Cc: Carlos Pignataro (cpignata); Frank Brockners (fbrockne); The I= AB;
>> iesg@ietf.org; ioam@ietf.org; Alvaro Retana (aretana); Spencer Dawk= ins at IETF
>> Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam)
>>
>> I would be very careful about using this proposal as a justificati= on for
>> an iOAM working group.
>> it is SFC specific.
>> And there are some interesting challenges in the details.
>>
>> Yours,
>> Joel
>>
>> On 2/10/17 12:09 PM, Ram Krishnan wrote:
>>> Very good discussion.
>>>
>>> Another aspect to note is that we see value for in-situ OAM fo= r
>>> monitoring network functions (especially virtual) besides netw= ork
>>> interconnects. This is captured in Section 3 in the draft
>>> (https://datatracker= .ietf.org/doc/draft-krishnan-opsawg-in-band-pro-
>> sla/?include_text=3D1).
>>>
>>> I believe IPPM charter addresses only network monitoring.
>>>
>>> Thanks,
>>> Ramki
>>>
>>> On Fri, Feb 10, 2017 at 7:11 AM, Mirja Kuehlewind (IETF)
>>> <ietf@kuehlewind.net= <mailto:ietf@kuehlewind.net<= /a>>> wrote:
>>>
>>>=C2=A0 =C2=A0 Hi Frank, hi all,
>>>
>>>=C2=A0 =C2=A0 please see in-line.
>>>
>>>> Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne)<= br> >>>=C2=A0 =C2=A0 <
fbrockn= e@cisco.com <mailto:fbrockne@c= isco.com>>:
>>>>
>>>> Hi Mirja,
>>>>
>>>> you raise an interesting point. The IPPM charter states=C2= =A0 "
>>>=C2=A0 =C2=A0 Specifying network or lower layer OAM mechanisms = is out of scope of
>>>=C2=A0 =C2=A0 the IPPM charter.", whereas the WG has "= ; Submit a draft on the IPv6
>>>=C2=A0 =C2=A0 Performance and Diagnostic Metrics (PDM) Destinat= ion Option as
>>>=C2=A0 =C2=A0 Proposed Standard
>>>> draft-ietf-ippm-6man-pdm-option" as a milestone.= I'd assume that
>>>=C2=A0 =C2=A0 we'd likely qualify IPv6 as a transport proto= col.
>>>
>>>=C2=A0 =C2=A0 If you also cite the sentence before this, this m= ight become clearer:
>>>
>>>=C2=A0 =C2=A0 "The IP Performance Metrics (IPPM) Working G= roup develops and maintains
>>>=C2=A0 =C2=A0 standard metrics that can be applied to the quali= ty, performance, and
>>>=C2=A0 =C2=A0 reliability of Internet data delivery services an= d applications running
>>>=C2=A0 =C2=A0 over transport layer protocols (e.g. TCP, UDP) ov= er IP. Specifying
>>>=C2=A0 =C2=A0 network
>>>=C2=A0 =C2=A0 or lower layer OAM mechanisms is out of scope of = the IPPM charter."
>>>
>>>=C2=A0 =C2=A0 It's focused on performance measurements of d= ata delivery services
>>>=C2=A0 =C2=A0 and application, not metric sthat are specific to= network operation
>>>=C2=A0 =C2=A0 e.g. up-time of a router (as an example that just= came to my mind).
>>>
>>>=C2=A0 =C2=A0 So to me the scope and the goals of IPPM and IOAM= are overlapping
>>>=C2=A0 =C2=A0 currently as for me "real-time telemetry of = individual data packets
>>>=C2=A0 =C2=A0 and flows" is exactly what IPPM is doing. >>>
>>>>
>>>> So far I understood the main focus of the new IOAM WG to b= e
>>>=C2=A0 =C2=A0 network-layer focused, i.e. piggyback OAM-meta-da= ta onto
>>>=C2=A0 =C2=A0 network-layer protocols - but that does not neces= sarily need to be
>>>=C2=A0 =C2=A0 always the case as you implicitly highlight by dr= awing the link to
>>>=C2=A0 =C2=A0 IPPM. One could also do so using e.g. TCP options= . I did not read
>>>=C2=A0 =C2=A0 the statement on IPPM in the draft charter as &qu= ot;not cooperating with
>>>=C2=A0 =C2=A0 IPPM" - I read it in a way that methods that= do not piggyback
>>>=C2=A0 =C2=A0 information on live traffic are not considered in= IOAM. That said,
>>>=C2=A0 =C2=A0 especially when it comes to export and interpreta= tion of in-situ OAM
>>>=C2=A0 =C2=A0 data, there might indeed be common ground between= IOAM and IPPM.
>>>
>>>=C2=A0 =C2=A0 My point is not that there needs to be cooperatio= n. My point is that
>>>=C2=A0 =C2=A0 we already have a working group that is mostly ch= arter to do what
>>>=C2=A0 =C2=A0 you want to do.
>>>
>>>=C2=A0 =C2=A0 Mirja
>>>
>>>
>>>>
>>>> How about we add another sentence to the charter that unde= rlines
>>>=C2=A0 =C2=A0 the fact that IOAM would actively seek cooperatio= n with other
>>>=C2=A0 =C2=A0 related efforts? We could add something like:
>>>>
>>>> "The IOAM WG seeks cooperation with other appropriate= standards
>>>=C2=A0 =C2=A0 bodies and forums to promote consistent approache= s, as well as
>>>=C2=A0 =C2=A0 definition and interpretation of in-situ OAM data= ."
>>>>
>>>> This would naturally capture IETF WGs like IPPM - but also= efforts
>>>=C2=A0 =C2=A0 like INT in P4, hence we'd even cast the net = a little wider.
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks, Frank
>>>>
>>>> -----Original Message-----
>>>> From: Ioam [mailto:ioam-bounces@ietf.org
>>>=C2=A0 =C2=A0 <mailto:ioam-bounces@ietf.org>] On Behalf Of Mirja Kuehlewind (IETF)=
>>>> Sent: Freitag, 10. Februar 2017 13:10
>>>> To: Carlos Pignataro (cpignata) <cpignata@cisco.com
>>>=C2=A0 =C2=A0 <mailto:= cpignata@cisco.com>>; Alvaro Retana (aretana)
>>>=C2=A0 =C2=A0 <aretana@= cisco.com <mailto:aretana@cisco= .com>>
>>>> Cc: iesg@ietf.org <= ;mailto:iesg@ietf.org>; The IAB <= ;iab@iab.org
>>>=C2=A0 =C2=A0 <mailto:iab@iab= .org>>; Spencer Dawkins at IETF
>>>=C2=A0 =C2=A0 <spencerdawkins.ietf@gmail.com
>>>=C2=A0 =C2=A0 <mailto:spencerdawkins.ietf@gmail.com>>; ioam@ietf.org
>>>=C2=A0 =C2=A0 <mailto:ioam@= ietf.org>
>>>> Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam)=
>>>>
>>>> Hi all,
>>>>
>>>> also one more comment on this point:
>>>>
>>>>> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpign= ata)
>>>=C2=A0 =C2=A0 <cpignat= a@cisco.com <mailto:cpignata@c= isco.com>>:
>>>>>
>>>>>>> Is there any connection with IPPM?
>>>>>
>>>>> Yes, there is, as already mentioned above.
>>>>
>>>>
>>>> The charter currently says:
>>>>
>>>> "Other ongoing OAM-related efforts in working groups(= s) such as
>>>=C2=A0 =C2=A0 MPLS and IPPM that do not piggyback information o= nto the live user
>>>=C2=A0 =C2=A0 data traffic are out of scope of the IOAM WG.&quo= t;
>>>>
>>>> which indictates that cooperation with IPPM is not planned= .
>>>>
>>>> To me in general the relation between this work and other = ongoing
>>>=C2=A0 =C2=A0 work in the IETF is not very clear and IPPM has s= everal documents
>>>=C2=A0 =C2=A0 and milestones that are in scope for this work: >>>>
>>>> - Submit a draft on the IPv6 Performance and Diagnostic Me= trics
>>>=C2=A0 =C2=A0 (PDM) Destination Option as Proposed Standard: >>>=C2=A0 =C2=A0 draft-ietf-ippm-6man-pdm-option (this draft = is mainly done and
>>>=C2=A0 =C2=A0 silenter the publication process soon to my under= standing)
>>>>
>>>> - Submit an Experimental draft on coloring-based hybrid >>>=C2=A0 =C2=A0 measurement methodologies for loss and delay to t= he IESG:
>>>=C2=A0 =C2=A0 draft-ietf-ippm-alt-mark-03
>>>>
>>>> I don't think that the assessment in the charter that = IPPM's scope
>>>=C2=A0 =C2=A0 does not include piggybacked information is corre= ct. Looking at
>>>=C2=A0 =C2=A0 draft-brockners-inband-oam-transport-02, I t= hink that any work on
>>>=C2=A0 =C2=A0 IPV6 and IPv6 in this scope should be done in IPP= M because that's
>>>=C2=A0 =C2=A0 were this work is already on-going and where the = measurement
>>>=C2=A0 =C2=A0 expertise is.
>>>>
>>>> Mirja
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ioam mailing list
>>>> Ioam@ietf.org <mai= lto:Ioam@ietf.org>
>>>> https://www.ietf.org/mailman/listinf= o/ioam
>>>=C2=A0 =C2=A0 <https://www.ietf.org/mailman= /listinfo/ioam>
>>>
>>>=C2=A0 =C2=A0 ____________________________________________= ___
>>>=C2=A0 =C2=A0 Ioam mailing list
>>>=C2=A0 =C2=A0 Ioam@ietf.org <mailto:Ioam@ietf.org>
>>>=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/ioam
>>>=C2=A0 =C2=A0 <https://www.ietf.org/mailman= /listinfo/ioam>
>>>
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Ramki
>>>
>>>
>>> _______________________________________________
>>> Ioam mailing list
>>> Ioam@ietf.org
>>> https://www.ietf.org/mailman/listinfo/io= am
>>>
>>
>> _______________________________________________
>> Ioam mailing list
>> Ioam@ietf.org
>> https://www.ietf.org/mailman/listinfo/ioam
>




--
Th= anks,=C2=A0
Ramki
--94eb2c1305721dfa2c054832b64d-- From nobody Sat Feb 11 02:47:08 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6888D12943F; Sat, 11 Feb 2017 02:47:03 -0800 (PST) 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=unavailable 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 vGX-9bE57S3j; Sat, 11 Feb 2017 02:47:01 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDB0129446; Sat, 11 Feb 2017 02:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=964; q=dns/txt; s=iport; t=1486810020; x=1488019620; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=XaNm/82RbomHjWJvQXLitUhqw02Jg/NdjmHoK+TripQ=; b=jJf8uBgCCm5BHtnepHjjEF8o3t7NwFUjLtk9fkzmQzEa9hK25SVPL8d3 uoa+Dfad2MKaiKjVIpsXHmYzt0iEfcxyvD9PM6aFjRNbwO/9/kndIjtxj /9Qv9MYJWfkNDSUnKqBg+isESt1akheCY39YQAkHyJBbVM/Pm6n6uaRox I=; X-IronPort-AV: E=Sophos;i="5.35,145,1484006400"; d="scan'208";a="207441486" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2017 10:47:00 +0000 Received: from [10.82.254.64] (rtp-vpn6-1594.cisco.com [10.82.254.64]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v1BAkvLA002562; Sat, 11 Feb 2017 10:46:58 GMT To: "Carlos Pignataro (cpignata)" , Stewart Bryant References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <5EADB2FC-9112-4C6F-956D-C9B0A7FA405F@cisco.com> <6F7EEE4C-2D31-438E-B672-49FEED30C1A4@cisco.com> <4f16e222-97e4-6f87-e1a3-79115db8f355@gmail.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <45cb7ac3-bca6-84fa-9cc0-b7ba3eec47f9@cisco.com> Date: Sat, 11 Feb 2017 05:46:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Alvaro Retana \(aretana\)" , The IAB , "ioam@ietf.org" , "iesg@ietf.org" , Spencer Dawkins at IETF Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 10:47:03 -0000 On 2/9/17 14:30, Carlos Pignataro (cpignata) wrote: >> I think the key distinguisher is really that in-situ is about embedding OAM meta-data in user data traffic. > > This is a good point. > > I agree. > > I believe this is already clear in the charter, all the way from the very first sentence: > > “ It is based on telemetry information which is embedded within live data packets.” > > Do you believe this is not clear in the charter? Do you have specific suggestions or concrete recommendations that can improve the charter text? I'm not sure this is clear (i.e., "live data"). Intuitively, I know what IOAM is trying to do, but the expression live data or even user data may not be ultimately clear as to the scope. For example, would IOAM headers be excluded from packets that did not have any data payload? Yeah, this is a bikeshed, but would text such as "packets within existing network flows" be better or clearer? Joe From nobody Mon Feb 13 06:48:35 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C9712968F for ; Mon, 13 Feb 2017 06:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 CttPOJ7eYuj9 for ; Mon, 13 Feb 2017 06:48:33 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 664F912968E for ; Mon, 13 Feb 2017 06:48:31 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v1DEeEqE005578 for ; Mon, 13 Feb 2017 06:48:25 -0800 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0b-0016f401.pphosted.com with ESMTP id 28j30kg2wk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 13 Feb 2017 06:48:25 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Feb 2017 16:48:22 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1210.000; Mon, 13 Feb 2017 16:48:22 +0200 From: Tal Mizrahi To: "ioam@ietf.org" Thread-Topic: Updated IOAM Proposed Charter Thread-Index: AdKGCBX8bMLyqjgkQH2qQf6p+TJzSw== Date: Mon, 13 Feb 2017 14:48:21 +0000 Message-ID: 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.4.102.210] Content-Type: multipart/alternative; boundary="_000_adeb1814acd74ebaafe10d4a5086ba0fILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-13_08:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound 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-1612050000 definitions=main-1702130144 Archived-At: Subject: [Ioam] Updated IOAM Proposed Charter X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 14:48:35 -0000 --_000_adeb1814acd74ebaafe10d4a5086ba0fILEXCH01marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The charter draft has been updated based on the comments received on the la= st few days: https://datatracker.ietf.org/doc/charter-ietf-ioam/ The main changes compared to the previous draft: - A few terminology and phrasing changes based on comments receive= d on the list. - New text regarding the encapsulations that the working group wil= l initially focus on. - Updated the text about consultation with other working groups. - New text about cooperation with other standard bodies. Comments will be welcome. Thanks, Tal. --_000_adeb1814acd74ebaafe10d4a5086ba0fILEXCH01marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The charter draft has been updated based on the comm= ents received on the last few days:

https://datatracker.ietf.org/doc/charter-ietf-ioam/

 

The main changes compared to the previous draft:

-     &= nbsp;    A few terminology and phra= sing changes based on comments received on the list.

-     &= nbsp;    New text regarding the enc= apsulations that the working group will initially focus on.

-     &= nbsp;    Updated the text about con= sultation with other working groups.

-     &= nbsp;    New text about cooperation= with other standard bodies.

 

Comments will be welcome.

 

Thanks,

Tal.

--_000_adeb1814acd74ebaafe10d4a5086ba0fILEXCH01marvellcom_-- From nobody Mon Feb 13 07:52:09 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6845A1296BE for ; Mon, 13 Feb 2017 07:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, 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=joelhalpern.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 cLBUUX5jrare for ; Mon, 13 Feb 2017 07:52:07 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 2DF4312966C for ; Mon, 13 Feb 2017 07:52:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 155776200BE; Mon, 13 Feb 2017 07:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1487001127; bh=jN4ZgtKgy2RSDK6EXs9byeVkXBHQb7QVqf3Y72ozcP0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=AwK+VuVHphyPyvjjNgEEXM5k0cfPDzrMc0v5/LfQMf1Jv2eQx943LSdT/d26hBUNp sLFlL4UIknqN5oMz9Gvg4Vsdq0K0ecg2Y/5eXW84JFPmZ8YOSbSBbvb5v+p6n9lM3W 1e24qbc3qEEtvq2pOcy9FxDlkPkjaw64TR1alglg= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9FE8B6200B5; Mon, 13 Feb 2017 07:52:06 -0800 (PST) To: Tal Mizrahi , "ioam@ietf.org" References: From: "Joel M. Halpern" Message-ID: <369755ec-7cb5-0127-3ac4-e97b1a2d1810@joelhalpern.com> Date: Mon, 13 Feb 2017 10:52:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ioam] Updated IOAM Proposed Charter X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:52:08 -0000 Maybe I am missing something, but it seems to me that issues such as ECMP and path MTU are not "domain" or "scope" specific. That is why I had asked that reference to these issues be put into the lead paragraph. Yours, Joel On 2/13/17 9:48 AM, Tal Mizrahi wrote: > Hi, > > > > The charter draft has been updated based on the comments received on the > last few days: > > https://datatracker.ietf.org/doc/charter-ietf-ioam/ > > > > The main changes compared to the previous draft: > > - A few terminology and phrasing changes based on comments > received on the list. > > - New text regarding the encapsulations that the working group > will initially focus on. > > - Updated the text about consultation with other working groups. > > - New text about cooperation with other standard bodies. > > > > Comments will be welcome. > > > > Thanks, > > Tal. > > > > _______________________________________________ > Ioam mailing list > Ioam@ietf.org > https://www.ietf.org/mailman/listinfo/ioam > From nobody Tue Feb 14 01:45:31 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D031296D7; Tue, 14 Feb 2017 01:45:29 -0800 (PST) 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, FREEMAIL_FROM=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 D__Om-yPdeXt; Tue, 14 Feb 2017 01:45:27 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::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 75A8612009C; Tue, 14 Feb 2017 01:45:27 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id c85so2626092wmi.1; Tue, 14 Feb 2017 01:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=kCU0JM3iGDocXywwFm1aklbZjGgVDfGLK+p1F+9Q+vk=; b=mKSjmub9yhQVJgBY8vjcnDcbp/a2kexYfcYUvIJIzvLnmiZ4rm2bJJVTX3ao2GI6Iv 9ERYQnSWfjquru8dqHW4ZHLY7SkLxvjPpG/NZTiQUZZkj2+VBsRFgylTWL9fybdRRQoe Hvx7IEVgMefgVoMyDG9/0PwLTzXPJ0RPzFjey2IzsGYs0AzSu1ZRIcNiPbuIKd5RmB1L cFUwYgMyblp9IevgNFqK4nji+JO9mK+7k+WrlVceqJEd+DsSKd2Gz2anhhplkGamuNvG 7JlDIMPq8zxLEbKVuuYCHYpwes4WpEOup4+n25k12a6Hgte6w+4mkIaG5KiG/B8UJSCb YPsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=kCU0JM3iGDocXywwFm1aklbZjGgVDfGLK+p1F+9Q+vk=; b=aPygOM0iry/nyG5ViUg/J3eN7q1Jv10Dl8g/gK/PsyZh2sZFEbhBWk19rTjIWe/xGV 4UF7cD6CjC1FpHNTwg91o+LrMp9idd6cTjcF6/QdjOmzLSGlr5QCy7CAI71/QqqKPxi5 4vKc1uUp9s0t4Qpc2ETR4w8Rh1rJK3TLTafQDY2nNHb/XvRvRnZsury6SYY8BdjH/nRC EzkEPNIALvvLZ64lKavYbAf3+UIwik46NotQOtLhH2XH9v153UBOeUr23Nc9b5LClOSI JeudG4iOjiFbnhVVevQCGcG96Gg8umEUBzf/C8pkL+Gf5X7UTaVFJPAZDOEJKTUQRWvs E3nA== X-Gm-Message-State: AMke39kC+fRxDGyyshX8vd7EXoDRubYZWrPngZSdekZ7CT2U6nxUa4rf0g/FZ0KN3Sl2+A== X-Received: by 10.28.27.69 with SMTP id b66mr2265820wmb.50.1487065525912; Tue, 14 Feb 2017 01:45:25 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id e74sm543560wmd.2.2017.02.14.01.45.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 01:45:25 -0800 (PST) To: "Carlos Pignataro (cpignata)" , Adrian Farrel References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <87206d4b-9b2c-f44c-754c-628e8c8e8887@cs.tcd.ie> <30D731F6-7073-486B-9395-BF1FC31F004C@cisco.com> <0be201d283ae$1b120680$51361380$@olddog.co.uk> <245E4E88-DBE4-49E5-A05E-EB46C0BF2928@cisco.com> From: Stewart Bryant Message-ID: <53a1587f-1f2a-d10e-9b96-6b8c539328c5@gmail.com> Date: Tue, 14 Feb 2017 09:45:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <245E4E88-DBE4-49E5-A05E-EB46C0BF2928@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Alvaro Retana \(aretana\)" , "ioam@ietf.org" , The IESG , The IAB , Stephen Farrell Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 09:45:29 -0000 On 10/02/2017 15:19, Carlos Pignataro (cpignata) wrote: >> On Feb 10, 2017, at 9:58 AM, Adrian Farrel wrote: >> >>>>> 1) I'm sure there are good things one can do with such >>>>> marking, but it is very unclear to me how this proposal >>>>> doesn't also fall afoul of all the privacy downsides of >>>>> the SPUD/PLUS proposal. My understanding of those privacy >>>>> downsides was that any generic/extensible marking scheme >>>>> (whether of packets or transport connections/flows) could >>>>> easily be abused in many privacy unfriendly ways. Note >>>>> that I'm not claiming there is IETF consensus on that >>>>> but I do claim it was a significant issue for SPUD/PLUS >>>>> and would like to know why (and hope) it is not an issue >>>>> here. Can someone help me understand what's different here >>>>> so we avoid that same kind of mega-debate? >>> Note that this proposal concerns itself with OAM information, and not as a >>> generic container for all-things. It is not for application information. >> Hmmm. >> Once you define a channel to carry other stuff along with data packets it will be used for purposes as yet undreamed of. > I understand that — which is true pretty much for any new protocol field. > > I was curious to see if there were more specifics on the PLUS discussion beyond this that particularly apply to IOAM. Adrian is correct here, but short of a breakthrough in cryptography that allows the use of homomorphic encryption at speed with small payloads, we sit on the horns of a dilemma between enhancing the legitimate observability of a network for management purposes and enhancing the observability for nefarious purposes. Perhaps the answer is to require all phys to include encryption? Stewart From nobody Tue Feb 14 01:57:34 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98321298AA; Tue, 14 Feb 2017 01:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 vY1ppt-Up62B; Tue, 14 Feb 2017 01:57:32 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F86B1294C4; Tue, 14 Feb 2017 01:57:31 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1E9vOp6030405; Tue, 14 Feb 2017 09:57:25 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1E9vKg0030337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2017 09:57:23 GMT From: "Adrian Farrel" To: "'Stewart Bryant'" , "'Carlos Pignataro \(cpignata\)'" References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <87206d4b-9b2c-f44c-754c-628e8c8e8887@cs.tcd.ie> <30D731F6-7073-486B-9395-BF1FC31F004C@cisco.com> <0be201d283ae$1b120680$51361380$@olddog.co.uk> <245E4E88-DBE4-49E5-A05E-EB46C0BF2928@cisco.com> <53a1587f-1f2a-d10e-9b96-6b8c539328c5@gmail.com> In-Reply-To: <53a1587f-1f2a-d10e-9b96-6b8c539328c5@gmail.com> Date: Tue, 14 Feb 2017 09:57:19 -0000 Message-ID: <02fd01d286a8$bde38d00$39aaa700$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPa9VlOQLpUKVlo/4ITVNuqPkWhAIITfo/Aao35ZECviEHQQIHsdB5AwVAxu8Cj3a96aD+D7MQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22884.006 X-TM-AS-Result: No--23.093-10.0-31-10 X-imss-scan-details: No--23.093-10.0-31-10 X-TMASE-MatchedRID: 9d2LtCNB3NJNlZ1zEcyAY4+YSzwl92XTXs5nqGvDCfOsVbcspinhtPOU uGB9RLG7sX8sN4WYnypiwHPBw2/v6i0M1J9+iCGWtLDu9qtqKeHqLDg4PiQdIykRn4qIywauKKD m6CPX8N7CP+Q6V63q3dNAQopQUNi6NdyCBd6LtFfcWo5Vvs8MQrd2noO4P7rALraGNlLRahivmp qFRV6sXIwWUgJWbP/q4c4eZs1WD75R2cR2TyQKnkhEDfw/93BuLAnNohUyMa2qk1pNnRLcWnkd7 fgSbdRZAhfygQKSgZpGTZylE32TfRxasQ/5XsrIiWatZUOj6OsvNM1bSrP4J5jk0EbtghtXPDE1 dnzqe9j+4JIhj1N/fgqyGvL90r7X7VzWdf1uCr/TbR5agAsD11AsQ+5PgsP5nvbaEOoeixN9qTN wMiKD+ise7faAfC+J1yyUtQ8ZyaE28LK855iUimiYls8x2M90tB3OND1JunKbKItl61J/ybLn+0 Vm71Lcq7rFUcuGp/GsWV0bdkf4OQSTC8t6yZ3k Archived-At: Cc: "'Alvaro Retana \(aretana\)'" , ioam@ietf.org, 'The IESG' , 'The IAB' , 'Stephen Farrell' Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 09:57:33 -0000 My concern was about use of the in-situ OAM container for non-OAM = purposes. Such as, to allow an application to coordinate the use of the = payload data. Pending a conversation about whether that would be smart or stupid, I = think that any in-situ OAM mechanism needs to be carefully ringed around = with words that say what uses are unacceptable, and probably also words = that carefully define where in-situ OAM bytes are and are not allowed to = be added. I think we probably have (albeit implicit?) that in-situ OAM bytes are = not allowed to enter the domain. We should probably also have that they = can only be added/modified by "OAM applications" and not "data sources". = However, thin end of wedge? Will an application (perhaps a VoIP = application) not consider it legitimate to add in-situ OAM to get = feedback on the behavior of the network for its voice calls? And if so, = that opens the gates for any application to use in-situ OAM, and *that* = opens the possibility of two end-point applications using the in-situ = OAM mechanism to talk about *anything*. Adrian > -----Original Message----- > From: Stewart Bryant [mailto:stewart.bryant@gmail.com] > Sent: 14 February 2017 09:45 > To: Carlos Pignataro (cpignata); Adrian Farrel > Cc: Alvaro Retana (aretana); ioam@ietf.org; The IESG; The IAB; Stephen = Farrell > Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) >=20 >=20 >=20 > On 10/02/2017 15:19, Carlos Pignataro (cpignata) wrote: > >> On Feb 10, 2017, at 9:58 AM, Adrian Farrel = wrote: > >> > >>>>> 1) I'm sure there are good things one can do with such > >>>>> marking, but it is very unclear to me how this proposal > >>>>> doesn't also fall afoul of all the privacy downsides of > >>>>> the SPUD/PLUS proposal. My understanding of those privacy > >>>>> downsides was that any generic/extensible marking scheme > >>>>> (whether of packets or transport connections/flows) could > >>>>> easily be abused in many privacy unfriendly ways. Note > >>>>> that I'm not claiming there is IETF consensus on that > >>>>> but I do claim it was a significant issue for SPUD/PLUS > >>>>> and would like to know why (and hope) it is not an issue > >>>>> here. Can someone help me understand what's different here > >>>>> so we avoid that same kind of mega-debate? > >>> Note that this proposal concerns itself with OAM information, and = not as a > >>> generic container for all-things. It is not for application = information. > >> Hmmm. > >> Once you define a channel to carry other stuff along with data = packets it will > be used for purposes as yet undreamed of. > > I understand that =E2=80=94 which is true pretty much for any new = protocol field. > > > > I was curious to see if there were more specifics on the PLUS = discussion beyond > this that particularly apply to IOAM. >=20 > Adrian is correct here, but short of a breakthrough in cryptography = that > allows the use of homomorphic encryption at speed with small = payloads, > we sit on the horns of a dilemma between enhancing the legitimate > observability of a network for management purposes and enhancing the > observability for nefarious purposes. Perhaps the answer is to require > all phys to include encryption? >=20 > Stewart From nobody Tue Feb 14 04:21:52 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B3B1293E8; Tue, 14 Feb 2017 04:21:50 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 9ZrZH7kyQvK1; Tue, 14 Feb 2017 04:21:48 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::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 0E5C21295D6; Tue, 14 Feb 2017 04:21:48 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id v77so3288470wmv.0; Tue, 14 Feb 2017 04:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=qR33OR1M9J0dkx3q6FqhmXAehm82e6MmvVkrpvkzJ0g=; b=k1sZSAK1+nBXRdsnK17d20hT0Qpd1H3C+32vmt7fQxZPSSOTSy23jGNFEHe3af6od2 TI67XjDJbzbH+jslv9V2JLOUtl+9FftCAxl3GJP5Uk2SpkhoF4euOcQdmJHOm/zC49F/ rsxCfHdTd0egbGVyW50BXW6NIu/QXeM/2/s+7oyUYLej0EU9oJkhAe6ct6s+OlINPJ3b gVI5nIFE4G2tVPw/0XRXMzMX248gdk6EmHC/JkO4LfpNfIzKhsGhZrP4uFT5NUb0ub4c Yjtlv0uXYwe6AP/TrLNajPy1JRmaMyTUnOcEtBzVirDlwCqwdw8Byl1/MpCKt4Hp6JNb 9R8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qR33OR1M9J0dkx3q6FqhmXAehm82e6MmvVkrpvkzJ0g=; b=RaFwboXjEhIVInRHXHk9R3csRvb4qmLrAmT2nvFsKF6XY+QkpmWM5jbBDFbvHLcpqg DzGB6rFes+Mtb/baB4bNLfz1oxBwoTsafcjylFgsL7cpI7i/xORY2O4aw2zUdjIZzl1m RpenlclPSXdzIKZZM5COaxkpDWpeblWtkv0YYlahK+2WcVtmc6mxKujSG1F55Avs6wX+ IwPWNZJ/LzsZRbqAqZbK5InBXOFPCGVHkWc3mPHRpU07HtpLLHqd8UAgLFEVG82K6B3+ DNOycmfImUrmgiFKSOTgdqYLPIXHZLDD2Ecvh20nHKbTSieU8wKDVE7+viy6XYNEp2tG mWFw== X-Gm-Message-State: AMke39nD3bDV8bcKFjVwIMYDVSUhqUN3kZZbLiRX2HB+biO7orDN1N+bJjdIw8jWwdvtLg== X-Received: by 10.28.107.141 with SMTP id a13mr3186372wmi.61.1487074906503; Tue, 14 Feb 2017 04:21:46 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id y80sm614256wrb.12.2017.02.14.04.21.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 04:21:45 -0800 (PST) To: adrian@olddog.co.uk, "'Carlos Pignataro (cpignata)'" References: <148657872835.4362.4208222446069276322.idtracker@ietfa.amsl.com> <87206d4b-9b2c-f44c-754c-628e8c8e8887@cs.tcd.ie> <30D731F6-7073-486B-9395-BF1FC31F004C@cisco.com> <0be201d283ae$1b120680$51361380$@olddog.co.uk> <245E4E88-DBE4-49E5-A05E-EB46C0BF2928@cisco.com> <53a1587f-1f2a-d10e-9b96-6b8c539328c5@gmail.com> <02fd01d286a8$bde38d00$39aaa700$@olddog.co.uk> From: Stewart Bryant Message-ID: <7fca16de-e811-0b65-8c6f-4557eccc97d1@gmail.com> Date: Tue, 14 Feb 2017 12:21:44 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <02fd01d286a8$bde38d00$39aaa700$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "'Alvaro Retana \(aretana\)'" , ioam@ietf.org, 'The IESG' , 'The IAB' , 'Stephen Farrell' Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 12:21:50 -0000 I don't think it matters what we say, if people want to use it for other purposes they will pay money to their vendor of choice or to the open source community and it will happen. We can try locking down the code-points I suppose. What we really need is a simple method of adding this information under cryptographic cover. That way at least only authorised parties can look at it. Stewart On 14/02/2017 09:57, Adrian Farrel wrote: > My concern was about use of the in-situ OAM container for non-OAM purposes. Such as, to allow an application to coordinate the use of the payload data. > > Pending a conversation about whether that would be smart or stupid, I think that any in-situ OAM mechanism needs to be carefully ringed around with words that say what uses are unacceptable, and probably also words that carefully define where in-situ OAM bytes are and are not allowed to be added. > > I think we probably have (albeit implicit?) that in-situ OAM bytes are not allowed to enter the domain. We should probably also have that they can only be added/modified by "OAM applications" and not "data sources". However, thin end of wedge? Will an application (perhaps a VoIP application) not consider it legitimate to add in-situ OAM to get feedback on the behavior of the network for its voice calls? And if so, that opens the gates for any application to use in-situ OAM, and *that* opens the possibility of two end-point applications using the in-situ OAM mechanism to talk about *anything*. > > Adrian > >> -----Original Message----- >> From: Stewart Bryant [mailto:stewart.bryant@gmail.com] >> Sent: 14 February 2017 09:45 >> To: Carlos Pignataro (cpignata); Adrian Farrel >> Cc: Alvaro Retana (aretana); ioam@ietf.org; The IESG; The IAB; Stephen Farrell >> Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam) >> >> >> >> On 10/02/2017 15:19, Carlos Pignataro (cpignata) wrote: >>>> On Feb 10, 2017, at 9:58 AM, Adrian Farrel wrote: >>>> >>>>>>> 1) I'm sure there are good things one can do with such >>>>>>> marking, but it is very unclear to me how this proposal >>>>>>> doesn't also fall afoul of all the privacy downsides of >>>>>>> the SPUD/PLUS proposal. My understanding of those privacy >>>>>>> downsides was that any generic/extensible marking scheme >>>>>>> (whether of packets or transport connections/flows) could >>>>>>> easily be abused in many privacy unfriendly ways. Note >>>>>>> that I'm not claiming there is IETF consensus on that >>>>>>> but I do claim it was a significant issue for SPUD/PLUS >>>>>>> and would like to know why (and hope) it is not an issue >>>>>>> here. Can someone help me understand what's different here >>>>>>> so we avoid that same kind of mega-debate? >>>>> Note that this proposal concerns itself with OAM information, and not as a >>>>> generic container for all-things. It is not for application information. >>>> Hmmm. >>>> Once you define a channel to carry other stuff along with data packets it will >> be used for purposes as yet undreamed of. >>> I understand that — which is true pretty much for any new protocol field. >>> >>> I was curious to see if there were more specifics on the PLUS discussion beyond >> this that particularly apply to IOAM. >> >> Adrian is correct here, but short of a breakthrough in cryptography that >> allows the use of homomorphic encryption at speed with small payloads, >> we sit on the horns of a dilemma between enhancing the legitimate >> observability of a network for management purposes and enhancing the >> observability for nefarious purposes. Perhaps the answer is to require >> all phys to include encryption? >> >> Stewart From nobody Tue Feb 14 05:22:37 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0A612963E for ; Tue, 14 Feb 2017 05:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 dnYEataYIosG for ; Tue, 14 Feb 2017 05:22:35 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 0EFF912963C for ; Tue, 14 Feb 2017 05:22:34 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v1EDJmQY014170; Tue, 14 Feb 2017 05:22:34 -0800 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0b-0016f401.pphosted.com with ESMTP id 28kgn8520s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 14 Feb 2017 05:22:33 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 14 Feb 2017 15:22:31 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1210.000; Tue, 14 Feb 2017 15:22:31 +0200 From: Tal Mizrahi To: "Joel M. Halpern" , "ioam@ietf.org" Thread-Topic: [EXT] Re: [Ioam] Updated IOAM Proposed Charter Thread-Index: AQHShhEjNHF8YnnDbkW9TFsSwNMG+aFofe1A Date: Tue, 14 Feb 2017 13:22:30 +0000 Message-ID: References: <369755ec-7cb5-0127-3ac4-e97b1a2d1810@joelhalpern.com> In-Reply-To: <369755ec-7cb5-0127-3ac4-e97b1a2d1810@joelhalpern.com> 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.4.102.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-14_08:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound 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-1612050000 definitions=main-1702140133 Archived-At: Subject: Re: [Ioam] [EXT] Re: Updated IOAM Proposed Charter X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 13:22:36 -0000 Hi Joel, Point well taken. I would suggest to split the following paragraph into two= paragraphs, one discussing the scope/domain, and the other discussing the = "various challenges". Please let us know if that addresses your concern. * Scope of in-situ OAM operation. In-Situ OAM operations are defined for a specific operational domain. In-situ OAM data-records are added and removed= at domain boundaries and updated by nodes within the in-situ OAM domain. Proce= dure to deal with various challenges in packet forwarding and error handling suc= h as ECMP processing, path MTU and ICMP message handling when in-situ OAM is ena= bled in an in-situ OAM domain. Thanks, Tal.=20 >-----Original Message----- >From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >Sent: Monday, February 13, 2017 5:52 PM >To: Tal Mizrahi; ioam@ietf.org >Subject: [EXT] Re: [Ioam] Updated IOAM Proposed Charter > >External Email > >---------------------------------------------------------------------- >Maybe I am missing something, but it seems to me that issues such as ECMP = and >path MTU are not "domain" or "scope" specific. That is why I had asked th= at >reference to these issues be put into the lead paragraph. > >Yours, >Joel > >On 2/13/17 9:48 AM, Tal Mizrahi wrote: >> Hi, >> >> >> >> The charter draft has been updated based on the comments received on >> the last few days: >> >> https://datatracker.ietf.org/doc/charter-ietf-ioam/ >> >> >> >> The main changes compared to the previous draft: >> >> - A few terminology and phrasing changes based on comments >> received on the list. >> >> - New text regarding the encapsulations that the working group >> will initially focus on. >> >> - Updated the text about consultation with other working groups= . >> >> - New text about cooperation with other standard bodies. >> >> >> >> Comments will be welcome. >> >> >> >> Thanks, >> >> Tal. >> >> >> >> _______________________________________________ >> Ioam mailing list >> Ioam@ietf.org >> https://www.ietf.org/mailman/listinfo/ioam >> From nobody Tue Feb 14 06:26:37 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CE7129A64 for ; Tue, 14 Feb 2017 06:26:35 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 9fqHYab_q5iI for ; Tue, 14 Feb 2017 06:26:34 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 28504129A63 for ; Tue, 14 Feb 2017 06:26:34 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v1EEKAkS024255; Tue, 14 Feb 2017 06:26:29 -0800 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 28j0urh6aw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 14 Feb 2017 06:26:28 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 14 Feb 2017 16:26:24 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1210.000; Tue, 14 Feb 2017 16:26:24 +0200 From: Tal Mizrahi To: Tal Mizrahi , "ioam@ietf.org" , "Stephen Farrell" , "Alvaro Retana (aretana) (aretana@cisco.com)" Thread-Topic: [EXT] [Ioam] Updated IOAM Proposed Charter Thread-Index: AQHShs5SGmJjQ7+F4UiYBvnqXVdwkg== Date: Tue, 14 Feb 2017 14:26:24 +0000 Message-ID: References: In-Reply-To: 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.4.102.210] Content-Type: multipart/alternative; boundary="_000_dfc15b6a84a743d997595e040547346fILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-14_08:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound 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-1612050000 definitions=main-1702140142 Archived-At: Subject: Re: [Ioam] [EXT] Updated IOAM Proposed Charter X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 14:26:36 -0000 --_000_dfc15b6a84a743d997595e040547346fILEXCH01marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Another issue that was raised by Stephen: >1) I'm sure there are good things one can do with such marking, but it is = very >unclear to me how this proposal doesn't also fall afoul of all the privacy >downsides of the SPUD/PLUS proposal. My understanding of those privacy >downsides was that any generic/extensible marking scheme (whether of packe= ts >or transport connections/flows) could easily be abused in many privacy >unfriendly ways. Note that I'm not claiming there is IETF consensus on tha= t but I >do claim it was a significant issue for SPUD/PLUS and would like to know w= hy >(and hope) it is not an issue here. Can someone help me understand what's >different here so we avoid that same kind of mega-debate? To address this in the charter, I propose to add the following text to the = list of items the WG will work on: * Security aspects of in-situ OAM, including the potential vulnerabilities = of integrating hop-by-hop information to en-route traffic, and measures tha= t should be taken to mitigate them. Again, comments will be welcome. Cheers, Tal. From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Tal Mizrahi Sent: Monday, February 13, 2017 4:48 PM To: ioam@ietf.org Subject: [EXT] [Ioam] Updated IOAM Proposed Charter External Email ________________________________ Hi, The charter draft has been updated based on the comments received on the la= st few days: https://datatracker.ietf.org/doc/charter-ietf-ioam/ The main changes compared to the previous draft: - A few terminology and phrasing changes based on comments receive= d on the list. - New text regarding the encapsulations that the working group wil= l initially focus on. - Updated the text about consultation with other working groups. - New text about cooperation with other standard bodies. Comments will be welcome. Thanks, Tal. --_000_dfc15b6a84a743d997595e040547346fILEXCH01marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Another issue that was= raised by Stephen:

>1) I'm sure there are good things one can do = with such marking, but it is very

>unclear to me how this proposal doesn't also = fall afoul of all the privacy

>downsides of the SPUD/PLUS proposal. My under= standing of those privacy

>downsides was that any generic/extensible mar= king scheme (whether of packets

>or transport connections/flows) could easily = be abused in many privacy

>unfriendly ways. Note that I'm not claiming t= here is IETF consensus on that but I

>do claim it was a significant issue for SPUD/= PLUS and would like to know why

>(and hope) it is not an issue here. Can someo= ne help me understand what's

>different here so we avoid that same kind of = mega-debate?

 

 

To address this in the= charter, I propose to add the following text to the list of items the WG w= ill work on:

 

* Security aspects of = in-situ OAM, including the potential vulnerabilities of integrating hop-by-= hop information to en-route traffic, and measures that should be taken to m= itigate them.

 

 

Again, comments will b= e welcome.

 

Cheers,

Tal.=

 

 

From: Ioam [ma= ilto:ioam-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, February 13, 2017 4:48 PM
To: ioam@ietf.org
Subject: [EXT] [Ioam] Updated IOAM Proposed Charter

 

External Email


Hi,

 

The charter draft has been updated based on the comm= ents received on the last few days:

https://datatracker.ietf.org/doc/charter-ietf-ioam/

 

The main changes compared to the previous draft:

-     &= nbsp;    A few terminology and phra= sing changes based on comments received on the list.

-     &= nbsp;    New text regarding the enc= apsulations that the working group will initially focus on.

-     &= nbsp;    Updated the text about con= sultation with other working groups.

-     &= nbsp;    New text about cooperation= with other standard bodies.

 

Comments will be welcome.

 

Thanks,

Tal.

--_000_dfc15b6a84a743d997595e040547346fILEXCH01marvellcom_-- From nobody Tue Feb 14 06:51:34 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26CC127601 for ; Tue, 14 Feb 2017 06:51:32 -0800 (PST) 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, HTML_MESSAGE=0.001, 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] 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 uTdWBoQqwYma for ; Tue, 14 Feb 2017 06:51:31 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40056.outbound.protection.outlook.com [40.107.4.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A3D129630 for ; Tue, 14 Feb 2017 06:51:28 -0800 (PST) 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=YcqunQCUGXfp/qlsvRNCLuurpg5vSFoDG/liVZ6rg9c=; b=rSAfNSY0H34Q96OXaTfW64tHOM3kuQ6LbeKyLI5ENboreVgSABXAm7wQwvUrFqsNq//8W+lnKC7Xj6CmYbTpa8Fgb14jKaslZ2bwUN2FK5TitJtgv852c6wccUHVLl7yndXGp6W089uozAFNhy5yUdmP2QGR4vcZPxjSOy8v2Fw= Received: from HE1PR0501MB2138.eurprd05.prod.outlook.com (10.167.246.22) by HE1PR0501MB2138.eurprd05.prod.outlook.com (10.167.246.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 14 Feb 2017 14:51:25 +0000 Received: from HE1PR0501MB2138.eurprd05.prod.outlook.com ([10.167.246.22]) by HE1PR0501MB2138.eurprd05.prod.outlook.com ([10.167.246.22]) with mapi id 15.01.0888.026; Tue, 14 Feb 2017 14:51:25 +0000 From: David Mozes To: Tal Mizrahi , "ioam@ietf.org" , "Stephen Farrell" , "Alvaro Retana (aretana) (aretana@cisco.com)" Thread-Topic: [Ioam] [EXT] Updated IOAM Proposed Charter Thread-Index: AQHShs5b/4J0NVjQGU6SKcz6f41y66FoleSQ Date: Tue, 14 Feb 2017 14:51:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=davidm@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-office365-filtering-correlation-id: f8f06b12-9975-4823-90c7-08d454e8f366 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR0501MB2138; x-microsoft-exchange-diagnostics: 1; HE1PR0501MB2138; 7:/o3c6c1c2t9NY/OP+lT2/HZZ3ihVnKM0n56/n3wbw4OWe2JP9He7RX8V/RRGFLmCJDlwQPXM/QKhYQliDPr53UwZQ04GN+769Afz9vhWzZkPn9YNZgRerKMiNFAPCH04aqRv0visTcliZJsIP7r1oUtCN4PMnVulLW6CIUM4I1Pqu1IDWwaKnG7EiILP1CkSSCBb4Di33vODZohgY0GyEPqmBYlmmvqnnUj/qFdA2EjCuiZNELC3iQvbGhDwdOe7xnFiZ9Ivt40MZGvKCWexZ29v0rPnsuOEFv+GwUiDJ7kdgNsN3BDs/HIbN4CffgMYTHuOqEnb5rjVYWP0N+GeglPCbffjY3RnLjCM0Bpc0tSBd1QlefkCRGkcSAy0AixAXjKECu/KXNTZqbMM94/Xtv77p3RGGhw5ZaW/BPBY2wVFd1/Pu6thxg94jkPAYde4/k6oTAr2bt5KvBO7O5HEaTrDAFW9RWy3gxyaIsbg4i8aBcPdSAkA0DQpa/7SNAXiHQeBdrNm4AseGjne1T+JUg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(120809045254105)(192374486261705)(100405760836317)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:HE1PR0501MB2138; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0501MB2138; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39410400002)(39840400002)(39860400002)(39450400003)(39850400002)(377454003)(199003)(189002)(3660700001)(7696004)(8676002)(6506006)(54356999)(189998001)(101416001)(53936002)(68736007)(3280700002)(105586002)(81156014)(74316002)(76176999)(2420400007)(7736002)(5660300001)(81166006)(97736004)(54896002)(77096006)(25786008)(561944003)(9686003)(33656002)(8936002)(15650500001)(6436002)(606005)(50986999)(86362001)(7110500001)(102836003)(2900100001)(106356001)(99286003)(6306002)(2950100002)(92566002)(2501003)(10710500007)(2906002)(236005)(790700001)(122556002)(66066001)(3846002)(38730400002)(55016002)(229853002)(19609705001)(7906003)(106116001)(6246003)(6116002)(81003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0501MB2138; H:HE1PR0501MB2138.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0501MB2138D2CF0A5F30187F5B28F2B6580HE1PR0501MB2138_" MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 14:51:25.7251 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0501MB2138 Archived-At: Subject: Re: [Ioam] [EXT] Updated IOAM Proposed Charter X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 14:51:33 -0000 --_000_HE1PR0501MB2138D2CF0A5F30187F5B28F2B6580HE1PR0501MB2138_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nvo3 ? From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Tal Mizrahi Sent: Tuesday, February 14, 2017 4:26 PM To: Tal Mizrahi ; ioam@ietf.org; Stephen Farrell ; Alvaro Retana (aretana) (aretana@cisco.com) Subject: Re: [Ioam] [EXT] Updated IOAM Proposed Charter Hi, Another issue that was raised by Stephen: >1) I'm sure there are good things one can do with such marking, but it is = very >unclear to me how this proposal doesn't also fall afoul of all the privacy >downsides of the SPUD/PLUS proposal. My understanding of those privacy >downsides was that any generic/extensible marking scheme (whether of packe= ts >or transport connections/flows) could easily be abused in many privacy >unfriendly ways. Note that I'm not claiming there is IETF consensus on tha= t but I >do claim it was a significant issue for SPUD/PLUS and would like to know w= hy >(and hope) it is not an issue here. Can someone help me understand what's >different here so we avoid that same kind of mega-debate? To address this in the charter, I propose to add the following text to the = list of items the WG will work on: * Security aspects of in-situ OAM, including the potential vulnerabilities = of integrating hop-by-hop information to en-route traffic, and measures tha= t should be taken to mitigate them. Again, comments will be welcome. Cheers, Tal. From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Tal Mizrahi Sent: Monday, February 13, 2017 4:48 PM To: ioam@ietf.org Subject: [EXT] [Ioam] Updated IOAM Proposed Charter External Email ________________________________ Hi, The charter draft has been updated based on the comments received on the la= st few days: https://datatracker.ietf.org/doc/charter-ietf-ioam/ The main changes compared to the previous draft: - A few terminology and phrasing changes based on comments receive= d on the list. - New text regarding the encapsulations that the working group wil= l initially focus on. - Updated the text about consultation with other working groups. - New text about cooperation with other standard bodies. Comments will be welcome. Thanks, Tal. --_000_HE1PR0501MB2138D2CF0A5F30187F5B28F2B6580HE1PR0501MB2138_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nvo3 ?

 

From: Ioam [mailto:ioam-bounces@ietf.org] = On Behalf Of Tal Mizrahi
Sent: Tuesday, February 14, 2017 4:26 PM
To: Tal Mizrahi <talmi@marvell.com>; ioam@ietf.org; Stephen Fa= rrell <stephen.farrell@cs.tcd.ie>; Alvaro Retana (aretana) (aretana@c= isco.com) <aretana@cisco.com>
Subject: Re: [Ioam] [EXT] Updated IOAM Proposed Charter

 

Hi,<= /p>

 

Another issue that was raised by Stephen:

>1) I'm sure there are good things one can do = with such marking, but it is very

>unclear to me how this proposal doesn't also = fall afoul of all the privacy

>downsides of the SPUD/PLUS proposal. My under= standing of those privacy

>downsides was that any generic/extensible mar= king scheme (whether of packets

>or transport connections/flows) could easily = be abused in many privacy

>unfriendly ways. Note that I'm not claiming t= here is IETF consensus on that but I

>do claim it was a significant issue for SPUD/= PLUS and would like to know why

>(and hope) it is not an issue here. Can someo= ne help me understand what's

>different here so we avoid that same kind of = mega-debate?

 

 

To address this in the= charter, I propose to add the following text to the list of items the WG w= ill work on:

 

* Security aspects of = in-situ OAM, including the potential vulnerabilities of integrating hop-by-= hop information to en-route traffic, and measures that should be taken to m= itigate them.

 

 

Again, comments will b= e welcome.

 

Cheers,

Tal.=

 

 

From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, February 13, 2017 4:48 PM
To: ioam@ietf.org
Subject: [EXT] [Ioam] Updated IOAM Proposed Charter

 

External Email


Hi,

 

The charter draft has been updated based on the comm= ents received on the last few days:

https://datatracker.ietf.org/doc/charter-ietf-ioam/

 

The main changes compared to the previous draft:

-     &= nbsp;    A few terminology and phra= sing changes based on comments received on the list.

-     &= nbsp;    New text regarding the enc= apsulations that the working group will initially focus on.

-     &= nbsp;    Updated the text about con= sultation with other working groups.

-     &= nbsp;    New text about cooperation= with other standard bodies.

 

Comments will be welcome.

 

Thanks,

Tal.

--_000_HE1PR0501MB2138D2CF0A5F30187F5B28F2B6580HE1PR0501MB2138_-- From nobody Tue Feb 14 07:54:16 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487251294F8 for ; Tue, 14 Feb 2017 07:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=joelhalpern.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 N9pdXH19GXrf for ; Tue, 14 Feb 2017 07:54:12 -0800 (PST) Received: from mxa2.tigertech.net (mxa2.tigertech.net [208.80.4.162]) (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 D68BD129453 for ; Tue, 14 Feb 2017 07:54:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id BE5BD247368; Tue, 14 Feb 2017 07:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1487087652; bh=ZrA7ofhXp7DbDsUnzFo6Dh17JAEw1g0yNVWRyeX1AN0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Q8+TPuI4tx3MBGiC4RXQabrBbhmZny4FSo/K7GWwgpKrdezTuWVVrmP23r3Iojjxo 2DHYlcRRosKyMPYHNJEQkDWtQVjvdN2z7axymlvOSIDEUZpDCnjFvHRqDpPBgGBPdw 2Wgpd+q+EvjKx9M2sthWET1GwQEESdKO5VamRKrI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 55A073A070C; Tue, 14 Feb 2017 07:54:12 -0800 (PST) To: Tal Mizrahi , "ioam@ietf.org" References: <369755ec-7cb5-0127-3ac4-e97b1a2d1810@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <0aaa5af4-bdbd-289c-db78-c68d3ad5c48d@joelhalpern.com> Date: Tue, 14 Feb 2017 10:54:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ioam] [EXT] Re: Updated IOAM Proposed Charter X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 15:54:14 -0000 Making the challenges a separate bullet would help. I might refer to challenges and constraints rather than just challenges. Yours, Joel On 2/14/17 8:22 AM, Tal Mizrahi wrote: > Hi Joel, > > Point well taken. I would suggest to split the following paragraph into two paragraphs, one discussing the scope/domain, and the other discussing the "various challenges". Please let us know if that addresses your concern. > > * Scope of in-situ OAM operation. In-Situ OAM operations are defined for a > specific operational domain. In-situ OAM data-records are added and removed at > domain boundaries and updated by nodes within the in-situ OAM domain. Procedure > to deal with various challenges in packet forwarding and error handling such as > ECMP processing, path MTU and ICMP message handling when in-situ OAM is enabled > in an in-situ OAM domain. > > Thanks, > Tal. > > > > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Monday, February 13, 2017 5:52 PM >> To: Tal Mizrahi; ioam@ietf.org >> Subject: [EXT] Re: [Ioam] Updated IOAM Proposed Charter >> >> External Email >> >> ---------------------------------------------------------------------- >> Maybe I am missing something, but it seems to me that issues such as ECMP and >> path MTU are not "domain" or "scope" specific. That is why I had asked that >> reference to these issues be put into the lead paragraph. >> >> Yours, >> Joel >> >> On 2/13/17 9:48 AM, Tal Mizrahi wrote: >>> Hi, >>> >>> >>> >>> The charter draft has been updated based on the comments received on >>> the last few days: >>> >>> https://datatracker.ietf.org/doc/charter-ietf-ioam/ >>> >>> >>> >>> The main changes compared to the previous draft: >>> >>> - A few terminology and phrasing changes based on comments >>> received on the list. >>> >>> - New text regarding the encapsulations that the working group >>> will initially focus on. >>> >>> - Updated the text about consultation with other working groups. >>> >>> - New text about cooperation with other standard bodies. >>> >>> >>> >>> Comments will be welcome. >>> >>> >>> >>> Thanks, >>> >>> Tal. >>> >>> >>> >>> _______________________________________________ >>> Ioam mailing list >>> Ioam@ietf.org >>> https://www.ietf.org/mailman/listinfo/ioam >>> From nobody Wed Feb 15 04:08:33 2017 Return-Path: X-Original-To: ioam@ietf.org Delivered-To: ioam@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1AF129440; Wed, 15 Feb 2017 04:08:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 04:08:32 -0800 Archived-At: Cc: ioam@ietf.org, ioam-chairs@ietf.org Subject: [Ioam] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 12:08:32 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-ioam-00-02: Block 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ioam/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- (1) I think we should have a BoF for this. Given the similarities with SPUD/PLUS (see [1] below) just going ahead and chartering this (and in RTG?) seems to be very badly inconsistent on behalf of the IESG, given the community concern about at least the meta-data insertion aspects in common. (And maybe more aspects.) (2) As with SPUD/PLUS I am very concerned at the potential privacy (not security) implications of any generic method of injecting meta-data whether that be into transport layer flows/sessions or at other layers. I do not see how doing that at any layer that can potentially span the Internet is different from doing the same thing at any other layer. I am concerned that there may not in fact be any acceptable solution for this problem (other than not aiming to allow any generic encoding), so I think this is something that does need to be discussed before external review happens. I am not convinced by the "domain" boundary argument in the charter - such things leak and/or the concept of "domain" is too ill-defined. A further point here is that the suggested timeline (data format defined in April 2017) clearly suggests that the idea here is to define a way to add a generic TLV structure to any packet, which I think equally clearly means that all of the privacy issues are relevant. (3) I assume the "M" in the name is for management. I don't see what would prevent someone developing a standardised ping of death if that is the case. (Or actually, possibly many flavours of that.) And actually that'd probably be inevitable if the "M" is really seriously meant. I am not sure that we (the IETF) would like that. That makes me wonder if the scope here is at all sufficiently well defined - is the implication of the name that the proponents want to be able to do all management functions this way, or just some? If just some, then which, and why is that a good idea? [1] https://www.ietf.org/proceedings/96/plus.html ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I remain unconvinced that this can go ahead before the IPv6 header processing discussion currently happening on ietf@ietf.org is resolved. - Were I mostly interested in "transport" issues, I'd be quite concerned about those as well - there are also things in common between this and SPUD/PLUS in that respect I figure, though I'm not anything like expert on that. From nobody Wed Feb 15 06:05:38 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9FE129561; Wed, 15 Feb 2017 06:05:37 -0800 (PST) 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 pC8qhY-sgMxZ; Wed, 15 Feb 2017 06:05:35 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 4D9E0120727; Wed, 15 Feb 2017 06:05:35 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v1FE5Jb1011760; Wed, 15 Feb 2017 06:05:32 -0800 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0b-0016f401.pphosted.com with ESMTP id 28kgn8ahjy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 15 Feb 2017 06:05:32 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Feb 2017 16:05:29 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1210.000; Wed, 15 Feb 2017 16:05:29 +0200 From: Tal Mizrahi To: Stephen Farrell , The IESG Thread-Topic: [EXT] [Ioam] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) Thread-Index: AQHSh4Q9m3nilJKKN0KOVb8IhOMRzqFqGYgg Date: Wed, 15 Feb 2017 14:05:28 +0000 Message-ID: References: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> In-Reply-To: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> 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.4.102.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-15_07:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound 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-1612050000 definitions=main-1702150136 Archived-At: Cc: "ioam@ietf.org" , "ioam-chairs@ietf.org" Subject: Re: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 14:05:37 -0000 Hi Stephen, Minor comment: as in [RFC6291] OAM in our context stands for Operations, Ad= ministration, and Maintenance. Cheers, Tal. >-----Original Message----- >From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Stephen Farrell >Sent: Wednesday, February 15, 2017 2:09 PM >To: The IESG >Cc: ioam@ietf.org; ioam-chairs@ietf.org >Subject: [EXT] [Ioam] Stephen Farrell's Block on charter-ietf-ioam-00-02: = (with >BLOCK and COMMENT) > >External Email > >---------------------------------------------------------------------- >Stephen Farrell has entered the following ballot position for >charter-ietf-ioam-00-02: Block > >When responding, please keep the subject line intact and reply to all emai= l >addresses included in the To and CC lines. (Feel free to cut this introduc= tory >paragraph, however.) > > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/charter-ietf-ioam/ > > > >---------------------------------------------------------------------- >BLOCK: >---------------------------------------------------------------------- > > >(1) I think we should have a BoF for this. Given the similarities with SPU= D/PLUS >(see [1] below) just going ahead and chartering this (and in RTG?) seems t= o be >very badly inconsistent on behalf of the IESG, given the community concern >about at least the meta-data insertion aspects in common. (And maybe more >aspects.) > >(2) As with SPUD/PLUS I am very concerned at the potential privacy (not >security) implications of any generic method of injecting meta-data whethe= r that >be into transport layer flows/sessions or at other layers. I do not see ho= w doing >that at any layer that can potentially span the Internet is different from= doing the >same thing at any other layer. I am concerned that there may not in fact b= e any >acceptable solution for this problem (other than not aiming to allow any g= eneric >encoding), so I think this is something that does need to be discussed bef= ore >external review happens. I am not convinced by the "domain" boundary >argument in the charter - such things leak and/or the concept of "domain" = is too >ill-defined. A further point here is that the suggested timeline (data for= mat >defined in April 2017) clearly suggests that the idea here is to define a = way to add >a generic TLV structure to any packet, which I think equally clearly means= that all >of the privacy issues are relevant. > >(3) I assume the "M" in the name is for management. I don't see what would >prevent someone developing a standardised ping of death if that is the cas= e. (Or >actually, possibly many flavours of that.) And actually that'd probably be >inevitable if the "M" is really seriously meant. I am not sure that we (th= e IETF) >would like that. That makes me wonder if the scope here is at all sufficie= ntly well >defined - is the implication of the name that the proponents want to be ab= le to do >all management functions this way, or just some? If just some, then which,= and >why is that a good idea? > >[1] https://www.ietf.org/proceedings/96/plus.html > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >- I remain unconvinced that this can go ahead before the IPv6 header proce= ssing >discussion currently happening on ietf@ietf.org is resolved. > >- Were I mostly interested in "transport" issues, I'd be quite concerned a= bout >those as well - there are also things in common between this and SPUD/PLUS= in >that respect I figure, though I'm not anything like expert on that. > > >_______________________________________________ >Ioam mailing list >Ioam@ietf.org >https://www.ietf.org/mailman/listinfo/ioam From nobody Wed Feb 15 06:10:10 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F07B1294CD; Wed, 15 Feb 2017 06:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-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=cs.tcd.ie 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 Eos6cuutwdTA; Wed, 15 Feb 2017 06:10:05 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05E1129416; Wed, 15 Feb 2017 06:10:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B882BBE51; Wed, 15 Feb 2017 14:10:03 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryVLvD7m_o8v; Wed, 15 Feb 2017 14:10:03 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A342ABE4D; Wed, 15 Feb 2017 14:10:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487167803; bh=27rpECbYRFgU9gNpAIlY5G9nYJDnnNg3UtSnE6tNt1Y=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=cvEvRLDfEqOfeKj+xPixB2BQfRKImNxdxtQIzChtU9OqdiPC6yTA6zKgAmmNmRZ62 vQv7obFWkc3PtpFA1UNEU7XSH55835RiQ0YVBY4ImMUVWEgT/BicS6I8RI6n0bXGYH m5RddO4UIA5ndGPtpO3Bj9q3plRnI70RlJINUwtI= To: Tal Mizrahi , The IESG References: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56e90519-5982-c9fe-9059-6f9e6497ca90@cs.tcd.ie> Date: Wed, 15 Feb 2017 14:10:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ov7eVvrKxR40XC4PQ1U6hItxTmNWsfnIN" Archived-At: Cc: "ioam@ietf.org" , "ioam-chairs@ietf.org" Subject: Re: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 14:10:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ov7eVvrKxR40XC4PQ1U6hItxTmNWsfnIN Content-Type: multipart/mixed; boundary="Lqd2AKrHFFJwTvO4nUGlrum0d52KLSMPH"; protected-headers="v1" From: Stephen Farrell To: Tal Mizrahi , The IESG Cc: "ioam@ietf.org" , "ioam-chairs@ietf.org" Message-ID: <56e90519-5982-c9fe-9059-6f9e6497ca90@cs.tcd.ie> Subject: Re: [EXT] [Ioam] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) References: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> In-Reply-To: --Lqd2AKrHFFJwTvO4nUGlrum0d52KLSMPH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 15/02/17 14:05, Tal Mizrahi wrote: > Hi Stephen, >=20 > Minor comment: as in [RFC6291] OAM in our context stands for > Operations, Administration, and Maintenance. Fair enough, thanks. The question in (3) though stands as to whether the scope includes (the moral equivalent) of a ping of death or not. Admin vs. Management in the acronym doesn't really impact on that. Cheers, S. >=20 > Cheers, Tal. >=20 >> -----Original Message----- From: Ioam >> [mailto:ioam-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: >> Wednesday, February 15, 2017 2:09 PM To: The IESG Cc: >> ioam@ietf.org; ioam-chairs@ietf.org Subject: [EXT] [Ioam] Stephen >> Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and >> COMMENT) >>=20 >> External Email >>=20 >> ----------------------------------------------------------------------= >> >>=20 Stephen Farrell has entered the following ballot position for >> charter-ietf-ioam-00-02: Block >>=20 >> 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.) >>=20 >>=20 >>=20 >> The document, along with other ballot positions, can be found >> here: https://datatracker.ietf.org/doc/charter-ietf-ioam/ >>=20 >>=20 >>=20 >> ----------------------------------------------------------------------= >> >>=20 BLOCK: >> ----------------------------------------------------------------------= >> >> >> >>=20 (1) I think we should have a BoF for this. Given the similarities with SPUD/PLUS >> (see [1] below) just going ahead and chartering this (and in RTG?) >> seems to be very badly inconsistent on behalf of the IESG, given >> the community concern about at least the meta-data insertion >> aspects in common. (And maybe more aspects.) >>=20 >> (2) As with SPUD/PLUS I am very concerned at the potential privacy >> (not security) implications of any generic method of injecting >> meta-data whether that be into transport layer flows/sessions or at >> other layers. I do not see how doing that at any layer that can >> potentially span the Internet is different from doing the same >> thing at any other layer. I am concerned that there may not in fact >> be any acceptable solution for this problem (other than not aiming >> to allow any generic encoding), so I think this is something that >> does need to be discussed before external review happens. I am not >> convinced by the "domain" boundary argument in the charter - such >> things leak and/or the concept of "domain" is too ill-defined. A >> further point here is that the suggested timeline (data format=20 >> defined in April 2017) clearly suggests that the idea here is to >> define a way to add a generic TLV structure to any packet, which I >> think equally clearly means that all of the privacy issues are >> relevant. >>=20 >> (3) I assume the "M" in the name is for management. I don't see >> what would prevent someone developing a standardised ping of death >> if that is the case. (Or actually, possibly many flavours of that.) >> And actually that'd probably be inevitable if the "M" is really >> seriously meant. I am not sure that we (the IETF) would like that. >> That makes me wonder if the scope here is at all sufficiently well=20 >> defined - is the implication of the name that the proponents want >> to be able to do all management functions this way, or just some? >> If just some, then which, and why is that a good idea? >>=20 >> [1] https://www.ietf.org/proceedings/96/plus.html >>=20 >>=20 >> ----------------------------------------------------------------------= >> >>=20 COMMENT: >> ----------------------------------------------------------------------= >> >> >> >>=20 - I remain unconvinced that this can go ahead before the IPv6 header processing >> discussion currently happening on ietf@ietf.org is resolved. >>=20 >> - Were I mostly interested in "transport" issues, I'd be quite >> concerned about those as well - there are also things in common >> between this and SPUD/PLUS in that respect I figure, though I'm not >> anything like expert on that. >>=20 >>=20 >> _______________________________________________ Ioam mailing list=20 >> Ioam@ietf.org https://www.ietf.org/mailman/listinfo/ioam >=20 --Lqd2AKrHFFJwTvO4nUGlrum0d52KLSMPH-- --Ov7eVvrKxR40XC4PQ1U6hItxTmNWsfnIN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYpGE5AAoJEC88hzaAX42iR9EH/igXx9Ai16xxvNPgf7SKAtpz 26GimPJsKOMzW/yxxofeJyqszejohCs1CGT4qnETnJ44g0H4QDkJJRVaHZSRO2bZ hT84LchbdhX5+vT+6QeCU+YgH7QoISbsZ5MW8Mk91Zj3OJdrx9LW3O8502w5aXWh iPKvm68k9q3IYTgRDenqkbsAZVuWFX1xmA/xM96wTl6fo9+1YN+frmPGed42YBAY LUHEfVLQhedCkzic2dPIoWSWupJAuA2f/DInW9HJYv9iC0KLL1THzWS5TsytYP2S xGGUz/4L9UNcydVwNFqMDBXDRAIaLDLex8iG1k/Zyyjxtdi5JZWJ4RJnzjry4wU= =pw+5 -----END PGP SIGNATURE----- --Ov7eVvrKxR40XC4PQ1U6hItxTmNWsfnIN-- From nobody Wed Feb 15 06:23:45 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9604F1295E7; Wed, 15 Feb 2017 06:23:40 -0800 (PST) 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 u-ZfApctO7k1; Wed, 15 Feb 2017 06:23:39 -0800 (PST) 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 1532E12959D; Wed, 15 Feb 2017 06:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7398; q=dns/txt; s=iport; t=1487168619; x=1488378219; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jASkKHx7KsruB3aOU5RhryRiAzH2XFCpiQ1oYzfLDXc=; b=E4D6CAFIfXAydjMEJjh66OcES6JMoMts/oP7svx0IwRMN7nQeTLF3Ihu aUMrTViyM420gzUWpXtRNwfh8IZKJR/0sORThx2hzJgWqosyiEVTsX1qW IlQ01GZARBYrN4JOM1O7MbRBvliy9pF+9acumFzSTYCgfXKQfjIej5t9K U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtAQCsY6RY/4QNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1JhgQkHg1KKCJIQlTaCDB8LhXgCGoF4PxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBAwEBASERNwMLDAQCAQgRBAEBAQICIwMCAgIlCxQBCAgCBAENBQgMB4lIC?= =?us-ascii?q?A6vdoIli2IBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUKEb4QmEQEzgm+CXwW?= =?us-ascii?q?JDYY3jDMBhm6LHIIEhReJdJMWAR84eAhRFT2Ee4FIdQGHWYEhgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,166,1484006400"; d="scan'208";a="207080395" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Feb 2017 14:23:37 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v1FENbXT015678 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Feb 2017 14:23:37 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Feb 2017 08:23:36 -0600 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; Wed, 15 Feb 2017 08:23:37 -0600 From: "Frank Brockners (fbrockne)" To: Stephen Farrell , Tal Mizrahi , The IESG Thread-Topic: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) Thread-Index: AQHSh5Sd7Uzijpy2qESODFia5dx1kaFqf9CA//+dtkA= Date: Wed, 15 Feb 2017 14:23:36 +0000 Message-ID: <6358cd5fa666448bac92fd0770ee45d8@XCH-RCD-008.cisco.com> References: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> <56e90519-5982-c9fe-9059-6f9e6497ca90@cs.tcd.ie> In-Reply-To: <56e90519-5982-c9fe-9059-6f9e6497ca90@cs.tcd.ie> 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.190.229] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ioam@ietf.org" , "ioam-chairs@ietf.org" Subject: Re: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 14:23:40 -0000 U3RlcGhlbiwNCg0KbXkgcmVhZGluZyBvZiB0aGUgZHJhZnQgY2hhcnRlciBpcyB0aGF0IElPQU0g d291bGQgYmUgZm9jdXNlZCBvbiBnYXRoZXJpbmcgZGF0YSwgbm90IGludGVycHJldGluZyBkYXRh IG9uIG5ldHdvcmsgbm9kZXMuIEkuZS4gSU9BTSBpcyBmb3Igb3BlcmF0aW9ucyBzdXBwb3J0ICpu b3QqIGZvciBhY3RpdmUgbWFuYWdlbWVudCBvZiBub2Rlcy4gVGhpcyBpcyBhbHNvIHdoeSBTUFVE L1BMVVMgYXJlIHByb2JhYmx5IG9ydGhvZ29uYWwvY29tcGxlbWVudGFyeSwgYmVjYXVzZSBJIHVu ZGVyc3RhbmQgdGhvc2UgYXBwcm9hY2hlcyBhcyB0YXJnZXRpbmcgdGhlIGNvbW11bmljYXRpb24g YmV0d2VlbiBlbmQtc3lzdGVtIGFuZCBtaWRkbGUtYm94ZXMgZm9yIGNvbnRyb2wvbWFuYWdlbWVu dCBwdXJwb3Nlcy4gVGhlIGxhY2sgb2Yg4oCcY29udHJvbOKAnSBvciDigJxtYW5hZ2VtZW504oCd IHNob3VsZCBhbHNvIG1pdGlnYXRlIGEgbG90IG9mIHRoZSBzZWN1cml0eSBjb25jZXJucyBmb3Ig SU9BTSwgYmVjYXVzZSB3ZSBqdXN0IGdhdGhlciBkYXRhLCB3ZSBkb27igJl0IGludGVycHJldCBk YXRhIG9yIGFjdCBvbiBkYXRhIGluIElPQU0uDQoNClNvIG9uIHlvdXIgcXVlc3Rpb246IEEgInBp bmcgb2YgZGVhdGgiIHdvbid0IGJlIHBvc3NpYmxlIHdpdGggSU9BTSAuDQoNCkNoZWVycywgRnJh bmsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElvYW0gW21haWx0bzppb2Ft LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNClNlbnQ6IE1p dHR3b2NoLCAxNS4gRmVicnVhciAyMDE3IDE1OjEwDQpUbzogVGFsIE1penJhaGkgPHRhbG1pQG1h cnZlbGwuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogaW9hbUBpZXRmLm9yZzsg aW9hbS1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSW9hbV0gW0VYVF0gU3RlcGhlbiBG YXJyZWxsJ3MgQmxvY2sgb24gY2hhcnRlci1pZXRmLWlvYW0tMDAtMDI6ICh3aXRoIEJMT0NLIGFu ZCBDT01NRU5UKQ0KDQoNCkhpeWEsDQoNCk9uIDE1LzAyLzE3IDE0OjA1LCBUYWwgTWl6cmFoaSB3 cm90ZToNCj4gSGkgU3RlcGhlbiwNCj4gDQo+IE1pbm9yIGNvbW1lbnQ6IGFzIGluIFtSRkM2Mjkx XSBPQU0gaW4gb3VyIGNvbnRleHQgc3RhbmRzIGZvciANCj4gT3BlcmF0aW9ucywgQWRtaW5pc3Ry YXRpb24sIGFuZCBNYWludGVuYW5jZS4NCg0KRmFpciBlbm91Z2gsIHRoYW5rcy4NCg0KVGhlIHF1 ZXN0aW9uIGluICgzKSB0aG91Z2ggc3RhbmRzIGFzIHRvIHdoZXRoZXIgdGhlIHNjb3BlIGluY2x1 ZGVzICh0aGUgbW9yYWwgZXF1aXZhbGVudCkgb2YgYSBwaW5nIG9mIGRlYXRoIG9yIG5vdC4NCkFk bWluIHZzLiBNYW5hZ2VtZW50IGluIHRoZSBhY3JvbnltIGRvZXNuJ3QgcmVhbGx5IGltcGFjdCBv biB0aGF0Lg0KDQpDaGVlcnMsDQpTLg0KDQo+IA0KPiBDaGVlcnMsIFRhbC4NCj4gDQo+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBJb2FtIFttYWlsdG86aW9hbS1ib3VuY2VzQGll dGYub3JnXSANCj4+IE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwgU2VudDoNCj4+IFdlZG5l c2RheSwgRmVicnVhcnkgMTUsIDIwMTcgMjowOSBQTSBUbzogVGhlIElFU0cgQ2M6DQo+PiBpb2Ft QGlldGYub3JnOyBpb2FtLWNoYWlyc0BpZXRmLm9yZyBTdWJqZWN0OiBbRVhUXSBbSW9hbV0gU3Rl cGhlbiANCj4+IEZhcnJlbGwncyBCbG9jayBvbiBjaGFydGVyLWlldGYtaW9hbS0wMC0wMjogKHdp dGggQkxPQ0sgYW5kDQo+PiBDT01NRU5UKQ0KPj4gDQo+PiBFeHRlcm5hbCBFbWFpbA0KPj4gDQo+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+DQo+PiANClN0ZXBoZW4gRmFycmVsbCBoYXMgZW50ZXJl ZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4+IGNoYXJ0ZXItaWV0Zi1pb2Ft LTAwLTAyOiBCbG9jaw0KPj4gDQo+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBz dWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgDQo+PiBlbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgDQo+PiB0 aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPj4gDQo+PiANCj4+IA0KPj4g VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZA0KPj4gaGVyZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1p ZXRmLWlvYW0vDQo+PiANCj4+IA0KPj4gDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+DQo+PiAN CkJMT0NLOg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAtDQo+Pg0KPj4NCj4+DQo+PiANCigxKSBJIHRo aW5rIHdlIHNob3VsZCBoYXZlIGEgQm9GIGZvciB0aGlzLiBHaXZlbiB0aGUgc2ltaWxhcml0aWVz IHdpdGggU1BVRC9QTFVTDQo+PiAoc2VlIFsxXSBiZWxvdykganVzdCBnb2luZyBhaGVhZCBhbmQg Y2hhcnRlcmluZyB0aGlzIChhbmQgaW4gUlRHPykgDQo+PiBzZWVtcyB0byBiZSB2ZXJ5IGJhZGx5 IGluY29uc2lzdGVudCBvbiBiZWhhbGYgb2YgdGhlIElFU0csIGdpdmVuIHRoZSANCj4+IGNvbW11 bml0eSBjb25jZXJuIGFib3V0IGF0IGxlYXN0IHRoZSBtZXRhLWRhdGEgaW5zZXJ0aW9uIGFzcGVj dHMgaW4gDQo+PiBjb21tb24uIChBbmQgbWF5YmUgbW9yZSBhc3BlY3RzLikNCj4+IA0KPj4gKDIp IEFzIHdpdGggU1BVRC9QTFVTIEkgYW0gdmVyeSBjb25jZXJuZWQgYXQgdGhlIHBvdGVudGlhbCBw cml2YWN5IA0KPj4gKG5vdCBzZWN1cml0eSkgaW1wbGljYXRpb25zIG9mIGFueSBnZW5lcmljIG1l dGhvZCBvZiBpbmplY3RpbmcgDQo+PiBtZXRhLWRhdGEgd2hldGhlciB0aGF0IGJlIGludG8gdHJh bnNwb3J0IGxheWVyIGZsb3dzL3Nlc3Npb25zIG9yIGF0IA0KPj4gb3RoZXIgbGF5ZXJzLiBJIGRv IG5vdCBzZWUgaG93IGRvaW5nIHRoYXQgYXQgYW55IGxheWVyIHRoYXQgY2FuIA0KPj4gcG90ZW50 aWFsbHkgc3BhbiB0aGUgSW50ZXJuZXQgaXMgZGlmZmVyZW50IGZyb20gZG9pbmcgdGhlIHNhbWUg dGhpbmcgDQo+PiBhdCBhbnkgb3RoZXIgbGF5ZXIuIEkgYW0gY29uY2VybmVkIHRoYXQgdGhlcmUg bWF5IG5vdCBpbiBmYWN0IGJlIGFueSANCj4+IGFjY2VwdGFibGUgc29sdXRpb24gZm9yIHRoaXMg cHJvYmxlbSAob3RoZXIgdGhhbiBub3QgYWltaW5nIHRvIGFsbG93IA0KPj4gYW55IGdlbmVyaWMg ZW5jb2RpbmcpLCBzbyBJIHRoaW5rIHRoaXMgaXMgc29tZXRoaW5nIHRoYXQgZG9lcyBuZWVkIHRv IA0KPj4gYmUgZGlzY3Vzc2VkIGJlZm9yZSBleHRlcm5hbCByZXZpZXcgaGFwcGVucy4gSSBhbSBu b3QgY29udmluY2VkIGJ5IA0KPj4gdGhlICJkb21haW4iIGJvdW5kYXJ5IGFyZ3VtZW50IGluIHRo ZSBjaGFydGVyIC0gc3VjaCB0aGluZ3MgbGVhayANCj4+IGFuZC9vciB0aGUgY29uY2VwdCBvZiAi ZG9tYWluIiBpcyB0b28gaWxsLWRlZmluZWQuIEEgZnVydGhlciBwb2ludCANCj4+IGhlcmUgaXMg dGhhdCB0aGUgc3VnZ2VzdGVkIHRpbWVsaW5lIChkYXRhIGZvcm1hdCBkZWZpbmVkIGluIEFwcmls IA0KPj4gMjAxNykgY2xlYXJseSBzdWdnZXN0cyB0aGF0IHRoZSBpZGVhIGhlcmUgaXMgdG8gZGVm aW5lIGEgd2F5IHRvIGFkZCBhIA0KPj4gZ2VuZXJpYyBUTFYgc3RydWN0dXJlIHRvIGFueSBwYWNr ZXQsIHdoaWNoIEkgdGhpbmsgZXF1YWxseSBjbGVhcmx5IA0KPj4gbWVhbnMgdGhhdCBhbGwgb2Yg dGhlIHByaXZhY3kgaXNzdWVzIGFyZSByZWxldmFudC4NCj4+IA0KPj4gKDMpIEkgYXNzdW1lIHRo ZSAiTSIgaW4gdGhlIG5hbWUgaXMgZm9yIG1hbmFnZW1lbnQuIEkgZG9uJ3Qgc2VlIHdoYXQgDQo+ PiB3b3VsZCBwcmV2ZW50IHNvbWVvbmUgZGV2ZWxvcGluZyBhIHN0YW5kYXJkaXNlZCBwaW5nIG9m IGRlYXRoIGlmIHRoYXQgDQo+PiBpcyB0aGUgY2FzZS4gKE9yIGFjdHVhbGx5LCBwb3NzaWJseSBt YW55IGZsYXZvdXJzIG9mIHRoYXQuKSBBbmQgDQo+PiBhY3R1YWxseSB0aGF0J2QgcHJvYmFibHkg YmUgaW5ldml0YWJsZSBpZiB0aGUgIk0iIGlzIHJlYWxseSBzZXJpb3VzbHkgDQo+PiBtZWFudC4g SSBhbSBub3Qgc3VyZSB0aGF0IHdlICh0aGUgSUVURikgd291bGQgbGlrZSB0aGF0Lg0KPj4gVGhh dCBtYWtlcyBtZSB3b25kZXIgaWYgdGhlIHNjb3BlIGhlcmUgaXMgYXQgYWxsIHN1ZmZpY2llbnRs eSB3ZWxsIA0KPj4gZGVmaW5lZCAtIGlzIHRoZSBpbXBsaWNhdGlvbiBvZiB0aGUgbmFtZSB0aGF0 IHRoZSBwcm9wb25lbnRzIHdhbnQgdG8gDQo+PiBiZSBhYmxlIHRvIGRvIGFsbCBtYW5hZ2VtZW50 IGZ1bmN0aW9ucyB0aGlzIHdheSwgb3IganVzdCBzb21lPw0KPj4gSWYganVzdCBzb21lLCB0aGVu IHdoaWNoLCBhbmQgd2h5IGlzIHRoYXQgYSBnb29kIGlkZWE/DQo+PiANCj4+IFsxXSBodHRwczov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9wbHVzLmh0bWwNCj4+IA0KPj4gDQo+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+IC0NCj4+DQo+PiANCkNPTU1FTlQ6DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0N Cj4+DQo+Pg0KPj4NCj4+IA0KLSBJIHJlbWFpbiB1bmNvbnZpbmNlZCB0aGF0IHRoaXMgY2FuIGdv IGFoZWFkIGJlZm9yZSB0aGUgSVB2NiBoZWFkZXIgcHJvY2Vzc2luZw0KPj4gZGlzY3Vzc2lvbiBj dXJyZW50bHkgaGFwcGVuaW5nIG9uIGlldGZAaWV0Zi5vcmcgaXMgcmVzb2x2ZWQuDQo+PiANCj4+ IC0gV2VyZSBJIG1vc3RseSBpbnRlcmVzdGVkIGluICJ0cmFuc3BvcnQiIGlzc3VlcywgSSdkIGJl IHF1aXRlIA0KPj4gY29uY2VybmVkIGFib3V0IHRob3NlIGFzIHdlbGwgLSB0aGVyZSBhcmUgYWxz byB0aGluZ3MgaW4gY29tbW9uIA0KPj4gYmV0d2VlbiB0aGlzIGFuZCBTUFVEL1BMVVMgaW4gdGhh dCByZXNwZWN0IEkgZmlndXJlLCB0aG91Z2ggSSdtIG5vdCANCj4+IGFueXRoaW5nIGxpa2UgZXhw ZXJ0IG9uIHRoYXQuDQo+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gSW9hbSBtYWlsaW5nIGxpc3QgDQo+PiBJb2FtQGlldGYub3JnIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW9hbQ0KPiANCg0K From nobody Wed Feb 15 06:33:10 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5532712963C; Wed, 15 Feb 2017 06:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-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=cs.tcd.ie 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 HGSdi9QgdU0y; Wed, 15 Feb 2017 06:33:05 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A03129634; Wed, 15 Feb 2017 06:33:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A839BBE4C; Wed, 15 Feb 2017 14:33:02 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv1HNJPE3agk; Wed, 15 Feb 2017 14:33:02 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EC4B6BE49; Wed, 15 Feb 2017 14:33:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487169182; bh=CiqTm1Y54NpN8PtKtFFyTwYxyPj4z4nkMGODPCVS7q0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=z9n+CnTmm815Sm9V6MtF9f+/Z2tpUQJMKbSkm6Es0xJpN5PP4vumNcKGQnmp1EUse abISI+GawEMTuZlgyt9suN+RwiVau6dDL85hTdTZ6AMx9Zr3CxZb8aN3GBtnEO3wip Em7yDXjtHg947vm30Qc60qiqagESIVDzH0xk16NI= To: "Frank Brockners (fbrockne)" , Tal Mizrahi , The IESG References: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> <56e90519-5982-c9fe-9059-6f9e6497ca90@cs.tcd.ie> <6358cd5fa666448bac92fd0770ee45d8@XCH-RCD-008.cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 15 Feb 2017 14:33:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <6358cd5fa666448bac92fd0770ee45d8@XCH-RCD-008.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FmlHRqcj4D8HW0H4oi62aBbGwdKxXL1Aj" Archived-At: Cc: "ioam@ietf.org" , "ioam-chairs@ietf.org" Subject: Re: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 14:33:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FmlHRqcj4D8HW0H4oi62aBbGwdKxXL1Aj Content-Type: multipart/mixed; boundary="vOhWOD4Acbmu5hf8v5r4HefqQpu0ItXmQ"; protected-headers="v1" From: Stephen Farrell To: "Frank Brockners (fbrockne)" , Tal Mizrahi , The IESG Cc: "ioam@ietf.org" , "ioam-chairs@ietf.org" Message-ID: Subject: Re: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) References: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> <56e90519-5982-c9fe-9059-6f9e6497ca90@cs.tcd.ie> <6358cd5fa666448bac92fd0770ee45d8@XCH-RCD-008.cisco.com> In-Reply-To: <6358cd5fa666448bac92fd0770ee45d8@XCH-RCD-008.cisco.com> --vOhWOD4Acbmu5hf8v5r4HefqQpu0ItXmQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 15/02/17 14:23, Frank Brockners (fbrockne) wrote: > Stephen, >=20 > my reading of the draft charter is that IOAM would be focused on > gathering data, not interpreting data on network nodes.=20 I'm not clear what distinction you're making there sorry. (That's likely my ignorance, so sorry again:-) > I.e. IOAM is > for operations support *not* for active management of nodes.=20 That sounds good, but I think needs to be clearer. > This is > also why SPUD/PLUS are probably orthogonal/complementary, because I > understand those approaches as targeting the communication between > end-system and middle-boxes for control/management purposes.=20 The similarity to SPUD/PLUS mainly affects privacy and not the ping-of-death question. Once one can add any label with enough bits in it to a packet then the privacy issues arise. > The lack > of =E2=80=9Ccontrol=E2=80=9D or =E2=80=9Cmanagement=E2=80=9D should als= o mitigate a lot of the > security concerns for IOAM, because we just gather data, we don=E2=80=99= t > interpret data or act on data in IOAM. >=20 > So on your question: A "ping of death" won't be possible with IOAM . I don't get how it won't be possible - if you're considering anything extensible, what'd prevent someone defining such an extension later? Cheers, S. >=20 > Cheers, Frank >=20 > -----Original Message----- From: Ioam [mailto:ioam-bounces@ietf.org] > On Behalf Of Stephen Farrell Sent: Mittwoch, 15. Februar 2017 15:10=20 > To: Tal Mizrahi ; The IESG Cc: > ioam@ietf.org; ioam-chairs@ietf.org Subject: Re: [Ioam] [EXT] Stephen > Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) >=20 >=20 > Hiya, >=20 > On 15/02/17 14:05, Tal Mizrahi wrote: >> Hi Stephen, >>=20 >> Minor comment: as in [RFC6291] OAM in our context stands for=20 >> Operations, Administration, and Maintenance. >=20 > Fair enough, thanks. >=20 > The question in (3) though stands as to whether the scope includes > (the moral equivalent) of a ping of death or not. Admin vs. > Management in the acronym doesn't really impact on that. >=20 > Cheers, S. >=20 >>=20 >> Cheers, Tal. >>=20 >>> -----Original Message----- From: Ioam >>> [mailto:ioam-bounces@ietf.org] On Behalf Of Stephen Farrell >>> Sent: Wednesday, February 15, 2017 2:09 PM To: The IESG Cc:=20 >>> ioam@ietf.org; ioam-chairs@ietf.org Subject: [EXT] [Ioam] Stephen >>> Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and=20 >>> COMMENT) >>>=20 >>> External Email >>>=20 >>> ---------------------------------------------------------------------= >>> >>>=20 - >>>=20 >>>=20 > Stephen Farrell has entered the following ballot position for >>> charter-ietf-ioam-00-02: Block >>>=20 >>> 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.) >>>=20 >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found=20 >>> here: https://datatracker.ietf.org/doc/charter-ietf-ioam/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------= >>> >>>=20 - >>>=20 >>>=20 > BLOCK: >>> ---------------------------------------------------------------------= >>> >>>=20 - >>>=20 >>>=20 >>>=20 >>>=20 > (1) I think we should have a BoF for this. Given the similarities > with SPUD/PLUS >>> (see [1] below) just going ahead and chartering this (and in >>> RTG?) seems to be very badly inconsistent on behalf of the IESG, >>> given the community concern about at least the meta-data >>> insertion aspects in common. (And maybe more aspects.) >>>=20 >>> (2) As with SPUD/PLUS I am very concerned at the potential >>> privacy (not security) implications of any generic method of >>> injecting meta-data whether that be into transport layer >>> flows/sessions or at other layers. I do not see how doing that at >>> any layer that can potentially span the Internet is different >>> from doing the same thing at any other layer. I am concerned that >>> there may not in fact be any acceptable solution for this problem >>> (other than not aiming to allow any generic encoding), so I think >>> this is something that does need to be discussed before external >>> review happens. I am not convinced by the "domain" boundary >>> argument in the charter - such things leak and/or the concept of >>> "domain" is too ill-defined. A further point here is that the >>> suggested timeline (data format defined in April 2017) clearly >>> suggests that the idea here is to define a way to add a generic >>> TLV structure to any packet, which I think equally clearly means >>> that all of the privacy issues are relevant. >>>=20 >>> (3) I assume the "M" in the name is for management. I don't see >>> what would prevent someone developing a standardised ping of >>> death if that is the case. (Or actually, possibly many flavours >>> of that.) And actually that'd probably be inevitable if the "M" >>> is really seriously meant. I am not sure that we (the IETF) would >>> like that. That makes me wonder if the scope here is at all >>> sufficiently well defined - is the implication of the name that >>> the proponents want to be able to do all management functions >>> this way, or just some? If just some, then which, and why is that >>> a good idea? >>>=20 >>> [1] https://www.ietf.org/proceedings/96/plus.html >>>=20 >>>=20 >>> ---------------------------------------------------------------------= >>> >>>=20 - >>>=20 >>>=20 > COMMENT: >>> ---------------------------------------------------------------------= >>> >>>=20 - >>>=20 >>>=20 >>>=20 >>>=20 > - I remain unconvinced that this can go ahead before the IPv6 header > processing >>> discussion currently happening on ietf@ietf.org is resolved. >>>=20 >>> - Were I mostly interested in "transport" issues, I'd be quite=20 >>> concerned about those as well - there are also things in common=20 >>> between this and SPUD/PLUS in that respect I figure, though I'm >>> not anything like expert on that. >>>=20 >>>=20 >>> _______________________________________________ Ioam mailing list >>> Ioam@ietf.org https://www.ietf.org/mailman/listinfo/ioam >>=20 >=20 --vOhWOD4Acbmu5hf8v5r4HefqQpu0ItXmQ-- --FmlHRqcj4D8HW0H4oi62aBbGwdKxXL1Aj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYpGadAAoJEC88hzaAX42i8uAH/1uzgxX2ROMnYOhYw4xMkZA1 OJb01EZQiWR/QLqiUE5luKkceGZPVXGwfClhrMebnj9niClb1rByHurjgrYJ+FoY 5gXfM8pHyYLso0g0c9W6E1HzIfEkdjLUiRWH91RQwpto9Gc9aXeQiqx8yfVH/R2G K93YCWw0+ZHtUrR0vU3F+KfV7KRSh8HpHUx0vPEoMRqylXuwZTk3Qo2ZhiI45AzA GDizZPT8ZGcoiAt7S1jzYXvILTyENAbnStmow7JvZC085T73wITeJCy0+ivYQVJR 6kG/eFMnV00VXgIiHe5Y0vu+cjXEhMNWUwnKFZX0+NMN6lxL55knZ+WvDjvar0U= =5J1n -----END PGP SIGNATURE----- --FmlHRqcj4D8HW0H4oi62aBbGwdKxXL1Aj-- From nobody Wed Feb 15 07:00:04 2017 Return-Path: X-Original-To: ioam@ietf.org Delivered-To: ioam@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E89D129552; Wed, 15 Feb 2017 06:59:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148717079960.17368.17225516172036467632.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 06:59:59 -0800 Archived-At: Cc: ioam@ietf.org, ioam-chairs@ietf.org Subject: [Ioam] Spencer Dawkins' No Objection on charter-ietf-ioam-00-02: (with COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 15:00:00 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-ioam-00-02: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ioam/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not balloting BLOCK because my biggest question matches Stephen's BLOCK, but if he clears and I still have that question, I'd ballot BLOCK myself. Re: Stephen's BLOCK, I also don't understand how PLUS has privacy problems that IOAM doesn't have. I'd also like to push that discussion a bit, before chartering the work. I know IOAM hasn't agreed on data formats, but I'm curious how long (measured in bytes) IOAM records are expected to be, and what the plan for PMTU discovery will be, given that we think ICMP blocking makes PMTUD unreliable and PLPMTUD is only defined on a per-transport protocol basis. I'm especially curious since the charter (correctly, I think) notes that IOAM records at multiple levels of tunneling would be useful - won't each layer that includes IOAM records chew away at the PMTU available for higher-level protocols? This is the type of thing I'd hope for involvement from TSVWG about. If the answer turns out to be that today's Internet can do jumbo-frames comfortably, that would be awesome, and should set off a rousing round of protocol engineering that recognizes this new answer. I'm also curious if any of the metrics that IPPM has developed would be useful for IOAM (recognizing that the method of collecting information for metrics is different between IPPM and IOAM). Is there a plan to do a gap analysis, and see what new metrics are needed? From nobody Wed Feb 15 07:43:46 2017 Return-Path: X-Original-To: ioam@ietf.org Delivered-To: ioam@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C851270B4; Wed, 15 Feb 2017 07:43:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148717342429.17377.6916464420990520809.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 07:43:44 -0800 Archived-At: Cc: ioam@ietf.org, ioam-chairs@ietf.org Subject: [Ioam] Benoit Claise's No Objection on charter-ietf-ioam-00-02: (with COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 15:43:45 -0000 Benoit Claise has entered the following ballot position for charter-ietf-ioam-00-02: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ioam/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I believe this functionality is important for network manageability. As a reminder, this work got some support in OPSAWG. And yes, there is the famous community debate: manageability vs privacy ... as seen in the RFC 7258 text and ballots: While PM is an attack, other forms of monitoring that might fit the definition of PM can be beneficial and not part of any attack, e.g., network management functions monitor packets or flows and anti-spam mechanisms need to see mail message content. Some monitoring can even be part of the mitigation for PM, for example, certificate transparency [RFC6962] involves monitoring Public Key Infrastructure in ways that could detect some PM attack techniques. However, there is clear potential for monitoring mechanisms to be abused for PM, so this tension needs careful consideration in protocol design. Making networks unmanageable to mitigate PM is not an acceptable outcome, but ignoring PM would go against the consensus documented here. An appropriate balance will emerge over time as real instances of this tension are considered. I know the end users don't care about this, but some operators still have network to operate. Based on the recent IESG thread, the charter text could be improved, as discussed: - by Adrian Farrel: We want to define a layer-independent, encapsulation-independent generic data format for carrying any OAM information in user data packets. We expect this to be useful in the following list of forwarding encapsulations but the actual use of and encapsulation of this generic data format will be worked on in coordination with the working groups responsible for those encapsulations. - by Joe Clarke: For example, would IOAM headers be excluded from packets that did not have any data payload? Yeah, this is a bikeshed, but would text such as "packets within existing network flows" be better or clearer? - By Tal Mizrahi: [RFC6291] OAM in our context stands for Operations, Administration, and Maintenance. - Frank Brockners: IOAM would be focused on gathering data, not interpreting data on network nodes. I.e. IOAM is for operations support *not* for active management of nodes I'll most probably ballot yes when those clarifications are introduced. Note: in the end, I don't care in which area this work is done. What counts is the willingness to do work and the expertise. Regards, Benoit From nobody Wed Feb 15 07:54:36 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B06D1295D9; Wed, 15 Feb 2017 07:54:31 -0800 (PST) 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, 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 UZslSn_WPy-C; Wed, 15 Feb 2017 07:54:29 -0800 (PST) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::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 6AF7F1294E0; Wed, 15 Feb 2017 07:54:29 -0800 (PST) Received: by mail-lf0-x243.google.com with SMTP id q89so13786638lfi.1; Wed, 15 Feb 2017 07:54:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=W6hSwJvOkxifUXT9InlhRzEDNIOVQ+T17wpaX34RF3E=; b=AiATJ3rJ/AUZQj2XKfAhq9kV3f0Y312tocHHmiKerySalFgrKal3pL/JEaKL6UdNhJ /PVkDNrM30ngiLnFUMgumwFztVEgkTTx9CFgJCKN6e8qK83FRJQJzrQ9yRqFZpWW7itR SWMyIN9pnhxgUVvSjnbMCTNapv5wCptw4Kf8HSCmpS7nho2lKttGpeFGbi6GqJybipV4 h0LAhxzZRf5ydXAQXxLaoQP9ETX3Es7zrJnm+SbfPHCX7foVvjuiBt3ekncRwHEarFjD FzbtDG0VCSd8P2vTr+s0q248C3wz2+JCQ3DEACGSTvVTq3ypx+I19YM7vwPTZCpdmYtV Ac3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=W6hSwJvOkxifUXT9InlhRzEDNIOVQ+T17wpaX34RF3E=; b=Lnfo7dFxbxRCDSCfhL+1wS9F65KNRYpZe7BAUKXjtCQS8c8yyItQLTynJgO+LEvzz5 19I0yJTDbBlCr0Oll9jxF+9ude+7CBz0tZ1rNQbJWtJO2nY4Fn63bZnV2Mt0nHMVVQw/ kQfcOSMgmg2mb5qbe5gwouo6tvhI8NwTY2/Pzq9uBgRNV5n+NiYMH3i0Fy/6aJOqqmDB 5fB2qyg4vkLfUNNda8DZr68hJLbI35lx+ZAz3td2E9eJUBVIyjaU34uOFUG+z0UKTEkF BX1S1M+sIbjZmSYV1cNRS953cElNwpAV4lHpmh3EpyP4y5uiqF7vAIs/SdWtUrY+5OQZ p6sg== X-Gm-Message-State: AMke39k3Vc3N4nZ+dfXSrvABJmZGZUOvTuCh95bsl5QvI49nV6Y8OJw/pzGZa1uFEAxsRQ== X-Received: by 10.25.99.134 with SMTP id v6mr11853252lfi.170.1487174067358; Wed, 15 Feb 2017 07:54:27 -0800 (PST) Received: from [192.168.32.185] ([84.15.183.80]) by smtp.gmail.com with ESMTPSA id u126sm1046502lja.25.2017.02.15.07.54.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 07:54:26 -0800 (PST) To: Stephen Farrell References: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> From: Ignas Bagdonas Message-ID: <469f09db-b5e0-f9ad-d351-391d442eff43@gmail.com> Date: Wed, 15 Feb 2017 15:54:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ioam@ietf.org, The IESG , ioam-chairs@ietf.org Subject: Re: [Ioam] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 15:54:31 -0000 Hi Stephen, > (1) I think we should have a BoF for this. Given the > similarities with SPUD/PLUS (see [1] below) just going ahead > and chartering this (and in RTG?) seems to be very badly > inconsistent on behalf of the IESG, given the community > concern about at least the meta-data insertion aspects in > common. (And maybe more aspects.) SPUD is targetting a different layer and the problem scope for SPUD is very different than for IOAM. IOAM does not target to be a signalling mechanism as such, and its scope is on the internet layer and lower data plane encapsulations (below the path layer in that PLUS proposal). It is also not a bidirectional mechanism. Details in the charter to make this clear would help. > (2) As with SPUD/PLUS I am very concerned at the potential > privacy (not security) implications of any generic method of > injecting meta-data whether that be into transport layer > flows/sessions or at other layers. I do not see how doing that > at any layer that can potentially span the Internet is > different from doing the same thing at any other layer. It seems that a clarification of scope would be needed here - IOAM does not plan to address the end to end internet operation. It is targetted to a controlled environment typically under single administrative control, typically having clear edge boundaries, and typically constrained to a single data plane encapsulation domain (an example - data center fabric), and dealing with gathering of the operational packet level and network element operation data of that particular domain. While it may be used in a broader end to end network scope that at least is not the intention. > I am > concerned that there may not in fact be any acceptable > solution for this problem (other than not aiming to allow any > generic encoding), so I think this is something that does need > to be discussed before external review happens. I am not > convinced by the "domain" boundary argument in the charter - > such things leak and/or the concept of "domain" is too > ill-defined. It certainly is possible to extend the IOAM domain, the leaking aspect is a more difficult one as proper IOAM operation needs explicit support of it by the network elements. Not saying that is impossible to happen. Again, a more detailed scope description needs to be added to the charter. > A further point here is that the suggested > timeline (data format defined in April 2017) clearly suggests > that the idea here is to define a way to add a generic TLV > structure to any packet, which I think equally clearly means > that all of the privacy issues are relevant. Privacy issues are certainly relevant from the perspective of being able to see the recorded IOAM information. As for the TLVs, the preference from hardware implementation side is to have fixed field structures and not full TLVs. It is certainly possible (and likely) to have full TLV encodings, the important note is on the consumers of such packets - IOAM data is not expected to reach end systems for which the packets carrying IOAM are destined, it is removed at the boundary of the IOAM domain. > (3) I assume the "M" in the name is for management. I don't > see what would prevent someone developing a standardised ping > of death if that is the case. (Or actually, possibly many > flavours of that.) And actually that'd probably be inevitable > if the "M" is really seriously meant. I am not sure that we > (the IETF) would like that. That makes me wonder if the scope > here is at all sufficiently well defined - is the implication > of the name that the proponents want to be able to do all > management functions this way, or just some? If just some, then > which, and why is that a good idea? The goal of IOAM is not to define a universal all purpose manageability mechanism for all use cases. It is trying to address the limitations of having to inject separate OAM packets and try to deal with multiple paths, heuristics of network elements in trying to find out what payload type it is, and using exactly the path taken by the data packets, and not the possible approximation of the path by the injected OAM packets. > > - I remain unconvinced that this can go ahead before the IPv6 > header processing discussion currently happening on > ietf@ietf.org is resolved. Yes, that is important dependency. One option is to continue IOAM work on non-IPv6 based data planes and tunnelling mechanisms first and wait for IPv6 header discussion to come to a result. > - Were I mostly interested in "transport" issues, I'd be quite > concerned about those as well - there are also things in > common between this and SPUD/PLUS in that respect I figure, > though I'm not anything like expert on that. > IOAM is not a transport protocol as such - there is no end to end channel between the end systems, there is no end to end channel within the IOAM domain too - it is a unidirectional path metadata collection mechanism. Thank you for the comments - they identify the areas that need to be clarified in the charter. Ignas From nobody Wed Feb 15 08:21:50 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3051295F4; Wed, 15 Feb 2017 08:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no 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 j1wVdVFnrWU2; Wed, 15 Feb 2017 08:21:47 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707D3126579; Wed, 15 Feb 2017 08:21:47 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1FGLfHw029052; Wed, 15 Feb 2017 16:21:41 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1FGLNEp028927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2017 16:21:37 GMT From: "Adrian Farrel" To: "'Stephen Farrell'" , "'Frank Brockners \(fbrockne\)'" , "'Tal Mizrahi'" , "'The IESG'" References: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> <56e90519-5982-c9fe-9059-6f9e6497ca90@cs.tcd.ie> <6358cd5fa666448bac92fd0770ee45d8@XCH-RCD-008.cisco.com> In-Reply-To: Date: Wed, 15 Feb 2017 16:21:19 -0000 Message-ID: <072401d287a7$9717c010$c5474030$@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/AZmvTRgxU9TugAJ1Lg+t+WTXxAJAXalPAdu0rPsBbro0KgDLE9ZKoF6Zq6A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22886.007 X-TM-AS-Result: No--29.097-10.0-31-10 X-imss-scan-details: No--29.097-10.0-31-10 X-TMASE-MatchedRID: irl7E//xM97gpJkkN54KBu2z+g9Wb/sXuRiLMrkF73pH4a2iJdV4MQvx MaV6x4s8feHPnu31iHAVJO7iRcm6fMfMjt18MDaZJrjuWtraDtpF+3SPXMw7TOLdprnA5EQR6Jj 6zYvfFARcKZwALwMGs0/C7C10JE7vl0RBptHJuMS6pkTQud6O/22EnshdEio2Dko+EYiDQxHPTY o1Nwkfy+awlruCFTR8T8sRnQxSSqfdTNZM6RI8CWoCJ3XtBZawjlL/hujrw1vcWo5Vvs8MQiqQa lMhs4UB6i5zlFx/UHR3qJ37Ojwrqh2x50UbytBssyjQ53GdiCNqxW9c79DYM9cjCbPZgQnF6Zly P3mazsmLaDxfPEIN++s7USOi3SHK/QhRj4/WQnFpnryVaiXugL9ZdlL8eonaC24oEZ6SpSlND5/ KBbSwnPzffz+WOOti Archived-At: Cc: ioam@ietf.org, ioam-chairs@ietf.org Subject: Re: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: afarrel@juniper.net List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 16:21:49 -0000 > > my reading of the draft charter is that IOAM would be focused on > > gathering data, not interpreting data on network nodes. >=20 > I'm not clear what distinction you're making there sorry. > (That's likely my ignorance, so sorry again:-) Or possibly not your ignorance. "Focused on" may be the catch. I think it unlikely that a network node is not going to have to examine = some fields of the IOAM data in order to discover what it is supposed to = do (add an address, add a time stamp, send a response), and also I = should expect it has to parse a bit to work out where to place any = information that it adds to the data. Furthermore, I suspect that it is only a matter of time before it is = recognised that IOAM provides a cannel that can be used to configure and = enable/disable OAM (noting that such a mechanism was found to be useful = in MPLS and that it is improbable that a second channel - in addition to = the IOAM channel - would be opened for OAM control mechanisms). > > I.e. IOAM is > > for operations support *not* for active management of nodes. >=20 > That sounds good, but I think needs to be clearer. Like I say, I wouldn't put money on that remaining the case. So even if = the charter explicitly forbids active management of (OAM on) the nodes, = at some point there will need to be a recharter. Given that, you might = do well to recognise the fact up front. > > This is > > also why SPUD/PLUS are probably orthogonal/complementary, because I > > understand those approaches as targeting the communication between > > end-system and middle-boxes for control/management purposes. >=20 > The similarity to SPUD/PLUS mainly affects privacy and not the > ping-of-death question. Once one can add any label with enough > bits in it to a packet then the privacy issues arise. It may help to give an example or two of where the privacy issue arises. For example, knowing the path of packets in a network is (possibly) a = privacy issue for the owner of the network, but more likely it is a = security issue. Is knowledge of the path of the packets a privacy issue = for the end-user? I don't think so, but maybe it would open up = information about src/dst pairs and so disclose something? But the IOAM proponents are likely to answer that IOAM is "strictly = confined within a domain" and so the information is not visible outside = the network *except* as reported by subverted nodes or by network = sniffers. It seems to me that there is remarkably little protection = available against subverted nodes (maybe every node has to have its own = SA with every OAM MEP?), but that sniffers could be thwarted. Adrian From nobody Wed Feb 15 11:15:29 2017 Return-Path: X-Original-To: ioam@ietf.org Delivered-To: ioam@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C931293E0; Wed, 15 Feb 2017 11:15:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148718612784.28137.9536650993456531683.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 11:15:27 -0800 Archived-At: Cc: aretana@cisco.com, cmorgan@amsl.com, ioam-chairs@ietf.org, ioam@ietf.org Subject: [Ioam] ioam - New Meeting Session Request for IETF 98 X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:15:28 -0000 A new meeting session request has just been submitted by Cindy Morgan, on behalf of the ioam working group. --------------------------------------------------------- Working Group Name: In-situ OAM Area Name: Routing Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: opsawg, lime, rtgarea, nvo3, ippm, tsvwg, tsvarea, 6man, intarea People who must be present: Alvaro Retana Tal Mizrahi Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Feb 15 11:41:21 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866C2129531; Wed, 15 Feb 2017 11:41:20 -0800 (PST) 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 YpY2PTy5ZtbF; Wed, 15 Feb 2017 11:41:18 -0800 (PST) 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 7229D1294F4; Wed, 15 Feb 2017 11:41:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAR58649; Wed, 15 Feb 2017 19:41:15 +0000 (GMT) Received: from LHREML709-CAH.china.huawei.com (10.201.108.32) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Feb 2017 19:41:14 +0000 Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Feb 2017 19:41:14 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Wed, 15 Feb 2017 11:41:08 -0800 From: Haoyu song To: "afarrel@juniper.net" , "'Stephen Farrell'" , "'Frank Brockners (fbrockne)'" , "'Tal Mizrahi'" , "'The IESG'" Thread-Topic: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) Thread-Index: AQHSh5SgPVK/B0EoME2vUXXLJTfM+6FqoVeAgAADzACAAAKgAIAAHkOA//+vO9A= Date: Wed, 15 Feb 2017 19:41:08 +0000 Message-ID: <78A2745BE9B57D4F9D27F86655EB87F9257EC4A0@SJCEML703-CHM.china.huawei.com> References: <148716051224.17360.14931066801393091893.idtracker@ietfa.amsl.com> <56e90519-5982-c9fe-9059-6f9e6497ca90@cs.tcd.ie> <6358cd5fa666448bac92fd0770ee45d8@XCH-RCD-008.cisco.com> <072401d287a7$9717c010$c5474030$@juniper.net> In-Reply-To: <072401d287a7$9717c010$c5474030$@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.217.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58A4AEDB.027E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 64e60d8e3bfc18b936b2c0f32abe26d0 Archived-At: Cc: "ioam@ietf.org" , "ioam-chairs@ietf.org" Subject: Re: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-02: (with BLOCK and COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:41:20 -0000 I agree that the active management possibility can't be totally excluded. A= lso, the node doesn't only collect data, but also possibly process the data= in order to generate new OAM data.=20 I think it's fine to explicitly confine the IOAM into a single domain so th= e privacy is no longer a concern. This also eliminates many other issues. Haoyu=20 -----Original Message----- From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, February 15, 2017 8:21 AM To: 'Stephen Farrell' ; 'Frank Brockners (fbrock= ne)' ; 'Tal Mizrahi' ; 'The IESG' Cc: ioam@ietf.org; ioam-chairs@ietf.org Subject: Re: [Ioam] [EXT] Stephen Farrell's Block on charter-ietf-ioam-00-0= 2: (with BLOCK and COMMENT) > > my reading of the draft charter is that IOAM would be focused on=20 > > gathering data, not interpreting data on network nodes. >=20 > I'm not clear what distinction you're making there sorry. > (That's likely my ignorance, so sorry again:-) Or possibly not your ignorance. "Focused on" may be the catch. I think it unlikely that a network node is not going to have to examine som= e fields of the IOAM data in order to discover what it is supposed to do (a= dd an address, add a time stamp, send a response), and also I should expect= it has to parse a bit to work out where to place any information that it a= dds to the data. Furthermore, I suspect that it is only a matter of time before it is recogn= ised that IOAM provides a cannel that can be used to configure and enable/d= isable OAM (noting that such a mechanism was found to be useful in MPLS and= that it is improbable that a second channel - in addition to the IOAM chan= nel - would be opened for OAM control mechanisms). > > I.e. IOAM is > > for operations support *not* for active management of nodes. >=20 > That sounds good, but I think needs to be clearer. Like I say, I wouldn't put money on that remaining the case. So even if the= charter explicitly forbids active management of (OAM on) the nodes, at som= e point there will need to be a recharter. Given that, you might do well to= recognise the fact up front. > > This is > > also why SPUD/PLUS are probably orthogonal/complementary, because I=20 > > understand those approaches as targeting the communication between=20 > > end-system and middle-boxes for control/management purposes. >=20 > The similarity to SPUD/PLUS mainly affects privacy and not the=20 > ping-of-death question. Once one can add any label with enough bits in=20 > it to a packet then the privacy issues arise. It may help to give an example or two of where the privacy issue arises. For example, knowing the path of packets in a network is (possibly) a priva= cy issue for the owner of the network, but more likely it is a security iss= ue. Is knowledge of the path of the packets a privacy issue for the end-use= r? I don't think so, but maybe it would open up information about src/dst p= airs and so disclose something? But the IOAM proponents are likely to answer that IOAM is "strictly confine= d within a domain" and so the information is not visible outside the networ= k *except* as reported by subverted nodes or by network sniffers. It seems = to me that there is remarkably little protection available against subverte= d nodes (maybe every node has to have its own SA with every OAM MEP?), but = that sniffers could be thwarted. Adrian _______________________________________________ Ioam mailing list Ioam@ietf.org https://www.ietf.org/mailman/listinfo/ioam From nobody Wed Feb 15 18:04:38 2017 Return-Path: X-Original-To: ioam@ietf.org Delivered-To: ioam@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BAE1294B7; Wed, 15 Feb 2017 18:04:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148721067522.31425.13222402850556334613.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 18:04:35 -0800 Archived-At: Cc: aretana@cisco.com, ioam@ietf.org, ioam-chairs@ietf.org Subject: [Ioam] Alissa Cooper's No Objection on charter-ietf-ioam-00-02: (with COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 02:04:35 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-ioam-00-02: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ioam/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't think this is ready for external review but Stephen is holding the block already. If this really is meant to specify a generic, extensible data format that one could stick pretty much any data into, then I agree that this has the same drawbacks as SPUD/PLUS. If the charter described a limited set of specific data fields to be standardized, then a determination could be made about whether the privacy/security risks could be adequately constrained with requirements related to such constraints reflected in the charter. This seems like a fundamental point that needs to be resolved. From nobody Wed Feb 15 20:54:32 2017 Return-Path: X-Original-To: ioam@ietf.org Delivered-To: ioam@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 805FC12996F; Wed, 15 Feb 2017 20:54:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148722086748.31421.12851182598271162879.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 20:54:27 -0800 Archived-At: Cc: aretana@cisco.com, ioam@ietf.org, ioam-chairs@ietf.org Subject: [Ioam] Suresh Krishnan's No Objection on charter-ietf-ioam-00-02: (with COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 04:54:27 -0000 Suresh Krishnan has entered the following ballot position for charter-ietf-ioam-00-02: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ioam/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would like to have a bit more clarity about the difference between the SRv6 and the IPv6 encapsulations and why two different ones are required. From nobody Thu Feb 16 06:07:52 2017 Return-Path: X-Original-To: ioam@ietf.org Delivered-To: ioam@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 828291295E3; Thu, 16 Feb 2017 06:07:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148725407051.15968.11749691001912054091.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 06:07:50 -0800 Archived-At: Cc: aretana@cisco.com, ioam@ietf.org, ioam-chairs@ietf.org Subject: [Ioam] Alia Atlas' No Objection on charter-ietf-ioam-00-02: (with COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:07:50 -0000 Alia Atlas has entered the following ballot position for charter-ietf-ioam-00-02: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ioam/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) I share Suresh's question about the difference between SRv6 and IPv6 for this work. 2) There are common hardware router architecture issues that this work should at least consider. This may lead to slightly different requirements and guidelines for software and hardware. For example, a packet is commonly split into a header that is sent to be processed and the payload that is stored away and not accessible. How much data is available for the header can vary widely and is not always a power of 2. This came up significantly during NVO3 discussions about encapsulation approaches. This consideration makes me question the practicality of carrying, for example, lists of data collected. The length of the extra information also can impact the ability to compute flow entropy; at a minimum this can impact the actual path taken by the selected traffic. Another example is the issue of unordered TLVs being more expensive for hardware processing; given the possibility of an application being able to insert the iOAM data, this could have negative impacts on router capabilities. 3) I share Stephen's concerns about security aspects. From nobody Thu Feb 16 06:18:16 2017 Return-Path: X-Original-To: ioam@ietf.org Delivered-To: ioam@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DA41299CF; Thu, 16 Feb 2017 06:18:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Deborah Brungard" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148725469531.15933.223315168898312900.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 06:18:15 -0800 Archived-At: Cc: aretana@cisco.com, ioam@ietf.org, ioam-chairs@ietf.org Subject: [Ioam] Deborah Brungard's No Objection on charter-ietf-ioam-00-02: (with COMMENT) X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:18:15 -0000 Deborah Brungard has entered the following ballot position for charter-ietf-ioam-00-02: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ioam/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Similar to the concerns of others, I think the description of the work needs better scoping, e.g. Adrian's comment. IETF, and the industry, have been evaluating a variety of solutions for supporting programmable networks. All have various tradeoffs, especially in terms of scale. Currently the charter mixes saying the working group will define the mechanisms and in other paragraphs says it will be done in the responsible working group for the encapsulation. I think this needs to be clearer and, if modifying, I prefer it is done in the responsible working group as the many previous discussions on in-situ OAM have shown what may seem a simple solution is not. From nobody Thu Feb 16 06:55:57 2017 Return-Path: X-Original-To: ioam@ietf.org Delivered-To: ioam@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBB3129638; Thu, 16 Feb 2017 06:55:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , "The IESG" , , X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148725695216.15884.7261938770608909535.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 06:55:52 -0800 From: IETF Secretariat Archived-At: Subject: [Ioam] Telechat update notice: X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:55:52 -0000 Removed from agenda for telechat ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-ioam/ From nobody Thu Feb 16 08:57:40 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C46129640 for ; Thu, 16 Feb 2017 08:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.022 X-Spam-Level: X-Spam-Status: No, score=-14.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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 EyrZFRNH-7cR for ; Thu, 16 Feb 2017 08:57:38 -0800 (PST) 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 D7A5F1295D9 for ; Thu, 16 Feb 2017 08:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7610; q=dns/txt; s=iport; t=1487264257; x=1488473857; h=from:to:subject:date:message-id:mime-version; bh=dxMUKfTsoUO1acXCQLmx0xj6w3xa8zub8+z4bIsYPDA=; b=ZUoSyYs9a0RKhVdIciwYFjY6wr+UbSDIuGQo9ChLgonJ6ko12TvZnm2I SmVUH519S6xrfqF88kXSrz3uOlY/AtwnQpf66eoRUMvIb//baKV52/rsf jQfWyG0AW9ewONlZ/k/tVRrs/+qqvae3SO93B+Jfa2Aes1fH+Izt9LWyk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAQB42aVY/5ldJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9iYYEQg1KKCKIXgx2CD4IMhj6Bcj8YAQIBAQEBAQEBYh0LhRpoAUo?= =?us-ascii?q?CBDAnBIl/oHCQBYIlK4sRAQEBAQEBBAEBAQEBAQEBIIZMggWKRC6CMQWVXIYjA?= =?us-ascii?q?YlJiE2Be4UXiXSTFwEfOIEAURU9EQGGMoofgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208,217";a="386538419" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 16:57:37 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1GGvatA007297 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Feb 2017 16:57:37 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 10:57:36 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 10:57:36 -0600 From: "Alvaro Retana (aretana)" To: "ioam@ietf.org" Thread-Topic: IOAM Work Moving Forward Thread-Index: AQHSiHXGRUbf8VhctECDRFBPmooW1A== Date: Thu, 16 Feb 2017 16:57:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_D6A076443D484BF3B4E58951A82A5951ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Ioam] IOAM Work Moving Forward X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:57:39 -0000 --_000_D6A076443D484BF3B4E58951A82A5951ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCkZpcnN0IG9mIGFsbCwgdGhhbmsgeW91IGFsbCBmb3IgdGhlIGludGVyZXN0IGV4cHJl c3NlZCBpbiB0aGlzIHRvcGljIGFuZCB0aGUgZGlzY3Vzc2lvbnMgYWJvdXQgdGhlIGNoYXJ0ZXIu DQoNCkFzIHlvdSBrbm93LCBvbmUgb2YgdGhlIGRpc2N1c3Npb25zIHJlc3VsdGluZyBmcm9tIHRo ZSBJbnRlcm5hbCBSZXZpZXcgb2YgdGhlIHByb3Bvc2VkIElPQU0gY2hhcnRlciB3YXMgd2hldGhl ciB0aGUgd29yayB3YXMgYWxyZWFkeSB3aXRoaW4gdGhlIGlwcG0gV0cgc2NvcGUgb3Igbm90LiAg T3ZlciB0aGUgbGFzdCBjb3VwbGUgb2YgZGF5cywgSSBoYXZlIGR1ZyBkZWVwZXIgaW50byB0aGF0 IHF1ZXN0aW9uIHdpdGggdGhlIFRyYW5zcG9ydCBBRHMgYW5kIHRoZSBpcHBtIFdHIENoYWlycywg YW5kIG91ciBjb25jbHVzaW9uIGlzIHRoYXQgdGhlcmUgaXMgc2lnbmlmaWNhbnQgb3ZlcmxhcCBi ZXR3ZWVuIHRoZSBjdXJyZW50IGlwcG0gQ2hhcnRlciBhbmQgdGhlIHByb3Bvc2VkIElPQU0gd29y ay4gIEVub3VnaCB0byBqdXN0aWZ5IG1vdmluZyB0aGUgd29yayBmb3J3YXJkIGluIHRoZSBpcHBt IFdHIGFuZCBub3Qgc3BsaW50ZXJpbmcgYSByZWxhdGVkIGVmZm9ydCBpbnRvIGEgbmV3IFdHLg0K DQpJIGhhdmUgdGhlbiBzdG9wcGVkIHRoZSBjaGFydGVyaW5nIGVmZm9ydCBmb3IgYSBuZXcgV0cu ICBUaGUgcHJvcG9uZW50cyB3aWxsIHN0YXJ0IGRpc2N1c3Npb25zIG9uIHRoZSBpcHBtIGxpc3Qg c29vbiDigJMgcGxlYXNlIGpvaW4gaWYgeW914oCZcmUgbm90IHRoZXJlIGFscmVhZHkuICBJIHdp bGwga2VlcCB0aGlzIGxpc3Qgb3BlbiBmb3IgYSBjb3VwbGUgbW9yZSBkYXlzLg0KDQpDbGVhcmx5 IHRoZXJlIGlzIGludGVyZXN0IGluIGRldmVsb3BpbmcgdGhpcyBjcm9zcy1hcmVhIHdvcmsgaW4g dGhlIElFVEYuICBJIGhvcGUgdGhhdCB5b3Ugd2lsbCBjb250aW51ZSB0byBwYXJ0aWNpcGF0ZSBh cyB0aGUgdG9waWMgcHJvZ3Jlc3NlcyBvbiB0aGUgaXBwbSBXRy4gIEl0IGlzIGltcG9ydGFudCB0 aGF0IHRoaXMgdHlwZSBvZiBjcm9zcy1hcmVhIGVmZm9ydHMgYmUgcHJvcGVybHkgZGlzY3Vzc2Vk IGFuZCB0aGF0IHdlIGRvbuKAmXQgY3JlYXRlIG1vcmUgc2lsb3MuICBJIHJlYWxpemUgaXQgdG9v ayB1cyBhIGNvdXBsZSBvZiB0cmllcyB0byBmaW5kIHdoYXQgSSB0aGluayBpcyBhIHN0YWJsZSBo b21lIGZvciB0aGUgSU9BTSB3b3JrIOKAkyBJIGtub3cgdGhhdCB0aGUgb3BlbiBkaXNjdXNzaW9u IGhhcyBvbmx5IGhlbHBlZCB0aGUgb3ZlcmFsbCBwcm9jZXNzLg0KDQpUaGFua3MhDQoNCkFsdmFy by4NCg== --_000_D6A076443D484BF3B4E58951A82A5951ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7 DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5r PSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGkhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5GaXJzdCBvZiBhbGwsIHRoYW5rIHlvdSBhbGwgZm9y IHRoZSBpbnRlcmVzdCBleHByZXNzZWQgaW4gdGhpcyB0b3BpYyBhbmQgdGhlIGRpc2N1c3Npb25z IGFib3V0IHRoZSBjaGFydGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+QXMgeW91IGtub3csIG9uZSBvZiB0aGUgZGlzY3Vzc2lvbnMgcmVzdWx0aW5nIGZyb20g dGhlIEludGVybmFsIFJldmlldyBvZiB0aGUgcHJvcG9zZWQgSU9BTSBjaGFydGVyIHdhcyB3aGV0 aGVyIHRoZSB3b3JrIHdhcyBhbHJlYWR5IHdpdGhpbiB0aGUgaXBwbSBXRyBzY29wZSBvciBub3Qu Jm5ic3A7IE92ZXIgdGhlIGxhc3QgY291cGxlIG9mIGRheXMsIEkgaGF2ZSBkdWcNCiBkZWVwZXIg aW50byB0aGF0IHF1ZXN0aW9uIHdpdGggdGhlIFRyYW5zcG9ydCBBRHMgYW5kIHRoZSBpcHBtIFdH IENoYWlycywgYW5kIG91ciBjb25jbHVzaW9uIGlzIHRoYXQgdGhlcmUgaXMgc2lnbmlmaWNhbnQg b3ZlcmxhcCBiZXR3ZWVuIHRoZSBjdXJyZW50IGlwcG0gQ2hhcnRlciBhbmQgdGhlIHByb3Bvc2Vk IElPQU0gd29yay4mbmJzcDsgRW5vdWdoIHRvIGp1c3RpZnkgbW92aW5nIHRoZSB3b3JrIGZvcndh cmQgaW4gdGhlIGlwcG0gV0cgYW5kIG5vdA0KIHNwbGludGVyaW5nIGEgcmVsYXRlZCBlZmZvcnQg aW50byBhIG5ldyBXRy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkkgaGF2ZSB0aGVuIHN0b3BwZWQgdGhlIGNoYXJ0ZXJpbmcgZWZmb3J0IGZvciBhIG5ldyBXRy4m bmJzcDsgVGhlIHByb3BvbmVudHMgd2lsbCBzdGFydCBkaXNjdXNzaW9ucyBvbiB0aGUgaXBwbSBs aXN0IHNvb24g4oCTIHBsZWFzZSBqb2luIGlmIHlvdeKAmXJlIG5vdCB0aGVyZSBhbHJlYWR5LiZu YnNwOyBJIHdpbGwga2VlcCB0aGlzIGxpc3Qgb3BlbiBmb3IgYSBjb3VwbGUgbW9yZQ0KIGRheXMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DbGVhcmx5IHRoZXJl IGlzIGludGVyZXN0IGluIGRldmVsb3BpbmcgdGhpcyBjcm9zcy1hcmVhIHdvcmsgaW4gdGhlIElF VEYuJm5ic3A7IEkgaG9wZSB0aGF0IHlvdSB3aWxsIGNvbnRpbnVlIHRvIHBhcnRpY2lwYXRlIGFz IHRoZSB0b3BpYyBwcm9ncmVzc2VzIG9uIHRoZSBpcHBtIFdHLiZuYnNwOyBJdCBpcyBpbXBvcnRh bnQgdGhhdCB0aGlzIHR5cGUgb2YgY3Jvc3MtYXJlYQ0KIGVmZm9ydHMgYmUgcHJvcGVybHkgZGlz Y3Vzc2VkIGFuZCB0aGF0IHdlIGRvbuKAmXQgY3JlYXRlIG1vcmUgc2lsb3MuJm5ic3A7IEkgcmVh bGl6ZSBpdCB0b29rIHVzIGEgY291cGxlIG9mIHRyaWVzIHRvIGZpbmQgd2hhdCBJIHRoaW5rIGlz IGEgc3RhYmxlIGhvbWUgZm9yIHRoZSBJT0FNIHdvcmsg4oCTIEkga25vdyB0aGF0IHRoZSBvcGVu IGRpc2N1c3Npb24gaGFzIG9ubHkgaGVscGVkIHRoZSBvdmVyYWxsIHByb2Nlc3MuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MhPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BbHZhcm8uPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D6A076443D484BF3B4E58951A82A5951ciscocom_-- From nobody Thu Feb 16 09:01:04 2017 Return-Path: X-Original-To: ioam@ietf.org Delivered-To: ioam@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B101297AC; Thu, 16 Feb 2017 09:00:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148726445492.15897.6452585074822245366.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 09:00:54 -0800 From: IETF Secretariat Archived-At: Subject: [Ioam] ID Tracker State Update Notice: X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:00:55 -0000 State changed to Not currently under review. ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-ioam/ From nobody Thu Feb 16 09:07:02 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E962129660; Thu, 16 Feb 2017 09:06:45 -0800 (PST) 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 gACSJt0YiB1q; Thu, 16 Feb 2017 09:06:43 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3574129646; Thu, 16 Feb 2017 09:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5578; q=dns/txt; s=iport; t=1487264801; x=1488474401; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OHixyAlnVnYxUG8TL67XnCP/q3s5X4PfQgPQ1j9biCA=; b=k3xRWeNnIxr167RZwgbMwDKf25a6iGzpkVyCI1F2gcZkTJuKGSVsGXWO dKYq9QxMzcd9bdLp8TCSg070i0YUnXatzslO6RCiTw/06KFM26uUgfE0N UZJGJoSIMBOpQ6A2CuNnxd2Aa7I4tZJD2dficyzMk6sc+iMAB9pdg/F8C Y=; X-Files: signature.asc : 859 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCk26VY/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVqSEJMkgg+CDCyFdgKCDD8YAQIBAQEBAQEBYh0LhHA?= =?us-ascii?q?BAQMCbgsMBAIBGQQBASgHAjAUCQgCBA4FCAaJXg6zDos5AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBDgoFhkyJFREBhgEFlVyGIwGDc4IHdYJaiESCBIUXiXSTFwEfOHg?= =?us-ascii?q?IURU9hkR1AYgIgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="asc'?scan'208";a="181333133" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Feb 2017 17:06:40 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1GH6eNN020459 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 17:06:40 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 11:06:40 -0600 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; Thu, 16 Feb 2017 11:06:39 -0600 From: "Frank Brockners (fbrockne)" To: "ippm@ietf.org" Thread-Topic: IOAM in IPPM Thread-Index: AQHSiGc9cXzuyNyh40uXrix8UqmsmqFryByA Date: Thu, 16 Feb 2017 17:06:39 +0000 Message-ID: References: <202517D0-A6CE-40D3-98BE-A2AFA8F83A19@trammell.ch> In-Reply-To: <202517D0-A6CE-40D3-98BE-A2AFA8F83A19@trammell.ch> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.190.229] Content-Type: multipart/mixed; boundary="_002_c50156b882bb4df0aab600d4b23f0ab1XCHRCD008ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "ioam@ietf.org" Subject: [Ioam] IOAM in IPPM X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:06:45 -0000 --_002_c50156b882bb4df0aab600d4b23f0ab1XCHRCD008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear IPPM WG, following the recommendation from the IPPM chairs (see also Brian's email b= elow) as well as ADs involved (see also Alvaro's email below) the discussio= ns on in-situ OAM (IOAM), we'd like the IPPM WG to consider adopting the IO= AM work, especially the definition of formats and associated procedures for= in-situ OAM, including mechanisms for capturing path and path-traversal re= lated information as well as procedures to employ, configure, trigger, and = export the embedded telemetry information. For this we'd suggest to adopt h= ttps://tools.ietf.org/html/draft-brockners-inband-oam-data-02 as a starting= point for the work of IPPM on IOAM. Like Brian noted, IPPM WG already focu= sses on hybrid measurements (e.g. those enabled by the similar draft-ietf-i= ppm-6man-pdm-option), hence IOAM would be a natural complement and addition= to that work and would benefit from all earlier work on metrics etc.=20 Background on In-situ OAM: In-situ OAM provides real-time telemetry of indi= vidual data packets and flows. It is based on telemetry information which i= s embedded within live user traffic, where "live user traffic" means packet= s originated and terminated at the application layer. For more information = on in-situ OAM, you could refer to the requirements draft we posted (draft-= brockners-inband-oam-requirements-02), or check out the presentations we ga= ve at IETF 96 and 97: https://www.ietf.org/proceedings/96/slides/slides-96-= opsawg-8.pdf and https://www.ietf.org/proceedings/97/slides/slides-97-opsaw= g-in-situ-oam-00.PDF=20 Appreciate your thoughts and support :-). Thanks, Frank -----Original Message----- From: Brian Trammell (IETF) [mailto:ietf@trammell.ch]=20 Sent: Donnerstag, 16. Februar 2017 16:13 To: Frank Brockners (fbrockne) Subject: IOAM in IPPM Hi, Frank, As we discussed today, please do introduce your draft (draft-brockners-inba= nd-oam-data-00) to the IPPM mailing list. Given our recent focus on hybrid = measurements (e.g. those enabled by the similar draft-ietf-ippm-6man-pdm-op= tion), I'd like to start a discussion there about considering the draft for= adoption within IPPM. Thanks, cheers, Brian -----Original Message----- From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Alvaro Retana (areta= na) Sent: Donnerstag, 16. Februar 2017 17:58 To: ioam@ietf.org Subject: [Ioam] IOAM Work Moving Forward Hi! First of all, thank you all for the interest expressed in this topic and th= e discussions about the charter. As you know, one of the discussions resulting from the Internal Review of t= he proposed IOAM charter was whether the work was already within the ippm W= G scope or not. Over the last couple of days, I have dug deeper into that = question with the Transport ADs and the ippm WG Chairs, and our conclusion = is that there is significant overlap between the current ippm Charter and t= he proposed IOAM work. Enough to justify moving the work forward in the ip= pm WG and not splintering a related effort into a new WG. I have then stopped the chartering effort for a new WG. The proponents wil= l start discussions on the ippm list soon - please join if you're not there= already. I will keep this list open for a couple more days. Clearly there is interest in developing this cross-area work in the IETF. = I hope that you will continue to participate as the topic progresses on the= ippm WG. It is important that this type of cross-area efforts be properly= discussed and that we don't create more silos. I realize it took us a cou= ple of tries to find what I think is a stable home for the IOAM work - I kn= ow that the open discussion has only helped the overall process. Thanks! Alvaro. --_002_c50156b882bb4df0aab600d4b23f0ab1XCHRCD008ciscocom_ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: signature.asc Content-Disposition: attachment; filename="signature.asc"; size=859; creation-date="Thu, 16 Feb 2017 17:06:39 GMT"; modification-date="Thu, 16 Feb 2017 17:06:39 GMT" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCkNvbW1lbnQ6IEdQR1Rvb2xzIC0gaHR0cHM6 Ly9ncGd0b29scy5vcmcNCg0KaVFJY0JBRUJDZ0FHQlFKWXBjR1VBQW9KRUlvU3Q3OEw2a2FqKzQ4 UC8yTVovaWI0Y2lYWkc4Vm5xTERkM3QyVA0KRWpEbUQ3cDhEdmFpdVZrcitIVTdiK2kxVGhrTnBt WkdsdVF0Y25nTlE2ZjRITUVlUkxGQUYyTTJQR1d1UVYyYw0KZFFQemlpaFIzQ3ZJSEFvS25JS2tL Y2d6NFJZSXRiRGEwRnVSM0I5amhhZVl0cUZLMFVCV2Vjb21jdTlJZkFpYw0KWHVUSWhsVmlNYVI3 UzEvNmdCdmVXODdxYm1TVVhOQVhrYVhSQ1ZmVll2dUc4d00rNzI3UUNGZVlhQUR1dmRNTg0KTnNu Q3YxakRCQzdFVVJxbFhUWVVwYXZrb0o0d3NpdU80S2l2VXNDWWpaSHU4OEZKMVZQL1hSa3ZlVDRl U0M3MQ0KT2R4aWpQOERNcVRJZzUxM0l1QkZJZmpBWHFUODV0YW5lUGxUN1JKNHRaVEpjNitMVTNj Zk5QLy9maWVxTjNKcg0KeldQOFZHSE1rbm10QTBBVjVQTU96Zk5lT0YvQkJLbkJjN21ZZmIydTRU RjJ5VnF3Wk5XY2ZiRy81MlNlMXNyWQ0KUGxlVWVFakNidzNYNUcyVDNEL1dWVXFacnJLU0s2Vzky bzRkRFNpZWdsVUhwYUwvMDdmQ2QzdERnWGpjRXZ3SQ0KN0ZGRkVCcmp2ZkRueWV6TFdYc005T3kw elY4aFVQM0svMlVHQlhHK2FzR29qby9xUkV6eldYbXRjQ1J1blVQcQ0KTk40SEdMZHdwQXNrcmVY Sm9DTVY2N1I3Z2VDd05kSUY3MGY4dDl2emdjeG40WUhhMmpTanQ4Y0ExKzNSL01TYQ0KaEw2R29a cC9YOXRoTGVCcEtlZHRNSllvbVBSU09zeFFUVGNBcE44T1ZKdUxYNTNZR3FQa2t6M3lQSDBWb3dH Vw0KNUQ4U3YvenQ0OEY2eGtIZlNlL1INCj1wNmpQDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0t LS0NCg== --_002_c50156b882bb4df0aab600d4b23f0ab1XCHRCD008ciscocom_-- From nobody Thu Feb 16 09:24:39 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBA1129588; Thu, 16 Feb 2017 09:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 98BKse0BXjQS; Thu, 16 Feb 2017 09:24:36 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2737129663; Thu, 16 Feb 2017 09:24:35 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1GHOTvt010500; Thu, 16 Feb 2017 17:24:29 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1GHOPxL010474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2017 17:24:27 GMT From: "Adrian Farrel" To: "'Alvaro Retana \(aretana\)'" , References: In-Reply-To: Date: Thu, 16 Feb 2017 17:24:24 -0000 Message-ID: <098c01d28879$870afbb0$9520f310$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_098D_01D28879.870F6880" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLgtEfHVWzDuGgd2q3ULzjJHuxh559PiMzQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22890.000 X-TM-AS-Result: No--28.242-10.0-31-10 X-imss-scan-details: No--28.242-10.0-31-10 X-TMASE-MatchedRID: DuKherWvI/vRhEyb9f1sjqrxFQMz0ixcQa2sDHLkQ07M7zpEspqG/9CI Gp1nxfbc2YJ36PQpkbz/DoPobY5pZ/a4UzvE+ZLR7/U7JmMpiiFdymZBcuGGRKj5v7I4/SgYr5q ahUVerFxnGkA/6YPrAKIuDCRldjhADsC2Khf6fZcX2N9OpwN26NMGD8JuBXZPuu0N7j6PSiNDcs 8837hAGKir8/odPOUzT5h6mHJlcbuVvrCauBpuuth3b7/zBhN1Pllq4+7Psp90PA/ki2kI7BxJE X0k/k7OLiNvWfV40DdEdqKGnxMcYDGgk0AvH9/hndu3heVAxaMP4vBWNr0zgSA6eO+NDmAxJZ3D 0zKPh7H10yQNuo1OJZfucML7iAp6c1BeS/J6aN9dMrg609R9BKO4XjVpMlFdn+lpJmYuEaN7ltq yJvHgp/JOjUaxKXKqGSKDIgjU9nky499dCbQy8IoLoibgjVEX1WPYxCHVrqdgHzfrfdHEt4c0B5 OUL/u1M5qWMflCo4dwtismKfx+71mKiy1F9pgLQesjq8XPMbt3Bf9JIqsoeEbaqUVvLFsi++vNJ KekcWR9xQFIjQfO0oYCheGFuxsgL3m5ejCdaFGdCtkMrsOtOpkShYcLpGH9ZM25ZAWwDYZgEEZ9 y/pY4Y0id0pIhqxT15LlVZSTLD2SjpyB+ma+j3uTVkeYosXtOS0bT53qXdVT+oAjVn9e0ORqQAx bWD9+4vM1YF6AJbbVZ0g740lL+SIQ5mZ5SqHPtS2OXM0RlsoyC3xaB/bDLI89MZSRvKHkPljq92 cjkHWkqd/AzNL85A== Archived-At: Cc: ioam@ietf.org, ippm@ietf.org Subject: Re: [Ioam] IOAM Work Moving Forward X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:24:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_098D_01D28879.870F6880 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable [...scurries to subscribe to another mailing list] =20 Can the TSV ADs comment on whether there is a plan to re-charter IPPM: - To be applicable to network layer and lower - To be scoped beyond "metrics" (such as path trace) - To attend to more detail than "characterize the network paths under = test and/or the performance of transport and application layer protocols on=20 these paths" =20 Thanks, Adrian =20 From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Alvaro Retana = (aretana) Sent: 16 February 2017 16:58 To: ioam@ietf.org Subject: [Ioam] IOAM Work Moving Forward =20 Hi! =20 First of all, thank you all for the interest expressed in this topic and = the discussions about the charter. =20 As you know, one of the discussions resulting from the Internal Review = of the proposed IOAM charter was whether the work was already within the = ippm WG scope or not. Over the last couple of days, I have dug deeper = into that question with the Transport ADs and the ippm WG Chairs, and = our conclusion is that there is significant overlap between the current = ippm Charter and the proposed IOAM work. Enough to justify moving the = work forward in the ippm WG and not splintering a related effort into a = new WG. =20 I have then stopped the chartering effort for a new WG. The proponents = will start discussions on the ippm list soon =E2=80=93 please join if = you=E2=80=99re not there already. I will keep this list open for a = couple more days. =20 Clearly there is interest in developing this cross-area work in the = IETF. I hope that you will continue to participate as the topic = progresses on the ippm WG. It is important that this type of cross-area = efforts be properly discussed and that we don=E2=80=99t create more = silos. I realize it took us a couple of tries to find what I think is a = stable home for the IOAM work =E2=80=93 I know that the open discussion = has only helped the overall process. =20 Thanks! =20 Alvaro. ------=_NextPart_000_098D_01D28879.870F6880 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

[...scurries to subscribe to another mailing = list]

 

Can = the TSV ADs comment on whether there is a plan to re-charter = IPPM:

- To = be applicable to network layer and lower

- To = be scoped beyond "metrics" (such as path = trace)

- To = attend to more detail than "characterize the network paths under = test

= =C2=A0and/or the performance of = transport and application layer protocols on

=C2=A0=C2=A0these = paths"

 

Thanks,

Adrian

 

From: Ioam = [mailto:ioam-bounces@ietf.org] On Behalf Of Alvaro Retana = (aretana)
Sent: 16 February 2017 16:58
To: = ioam@ietf.org
Subject: [Ioam] IOAM Work Moving = Forward

 

Hi!<= /p>

 

First of all, thank = you all for the interest expressed in this topic and the discussions = about the charter.

 

As you know, one of = the discussions resulting from the Internal Review of the proposed IOAM = charter was whether the work was already within the ippm WG scope or = not.  Over the last couple of days, I have dug deeper into that = question with the Transport ADs and the ippm WG Chairs, and our = conclusion is that there is significant overlap between the current ippm = Charter and the proposed IOAM work.  Enough to justify moving the = work forward in the ippm WG and not splintering a related effort into a = new WG.

 

I have then stopped = the chartering effort for a new WG.  The proponents will start = discussions on the ippm list soon =E2=80=93 please join if = you=E2=80=99re not there already.  I will keep this list open for a = couple more days.

 

Clearly there is = interest in developing this cross-area work in the IETF.  I hope = that you will continue to participate as the topic progresses on the = ippm WG.  It is important that this type of cross-area efforts be = properly discussed and that we don=E2=80=99t create more silos.  I = realize it took us a couple of tries to find what I think is a stable = home for the IOAM work =E2=80=93 I know that the open discussion has = only helped the overall process.

 

Thanks!

 

Alvaro.

------=_NextPart_000_098D_01D28879.870F6880-- From nobody Thu Feb 16 09:50:51 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D727D1295A6; Thu, 16 Feb 2017 09:50:49 -0800 (PST) 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 MCCLGIShkmiP; Thu, 16 Feb 2017 09:50:48 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 083C7129406; Thu, 16 Feb 2017 09:50:48 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id u68so11914858ywg.0; Thu, 16 Feb 2017 09:50:47 -0800 (PST) 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=DFKjOB7aPGW381SXt7moGn30n9PKS8761kKd7mqIbaU=; b=WLARhtvsqcC1fx5Ri3NREX0uck6kLXxtRG9DtPvyHTeEYfri5eCBXwQHJZ9QPN0HC+ 1kc6jSfGwO0VkrjXur8d4WhtbipoTLnvCh7Iq8hJIQshykS3i4qfq6aLfBI/zWUUvXCa FW9Z46hB9bvoER+imlc6wi2Votta2/eKMVRhfeG0XbH0fELF5V1yYUAwLeXQuX9u2IlK CqrRSgvvbudMqswQg5Cb3afojN+bu83kVtzBiss2Bm6kZTHucAuGkoGa35U2+Z/V3EvR XU6B2F2MiuUO/dSuGA3gqLXajbGPNAQ93KClIBwiK7JWuIbc3h5dJXeTaTaWyqb0ADoN x4CQ== 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=DFKjOB7aPGW381SXt7moGn30n9PKS8761kKd7mqIbaU=; b=cpPu2MVdeTf83Lr3suixphGyvNISzT0XezoOYgALa2k2POW/dF7kxdsCRCq0u3RsVV BbcimUKLUjOfoltLmZ3EZYF0AxTRKMXOP+WAdTa/qnooOBxq+ajWOvRh4On4fjYRCIu4 YdC2rRZz2P/sKHJ3/SrMQx3MBygR7Q6+ssmOKPDvzfeVF9izTg2pIQZQraHVvDrr5cIC BTb5RHSNpYZTKkuSmyxEAbRRDvnoGNOENHMXS6yY07rpbOlQJSVTJ0IhiGJkdSkkxRkt UgArdXFhUKL+jmJ5osBtsYgnjIxY4s2chRe0Uls0OjayyER0GU7lB264QfLJpk854+gw cQDA== X-Gm-Message-State: AMke39l8GDYjAQ8S5ldOcm+9TNIOj81QXJe6fiYVd/XZt/0S4z728DnxMof9n1xNJtGEz+3ESyBlDAn47yamwA== X-Received: by 10.13.243.197 with SMTP id c188mr2559768ywf.248.1487267447203; Thu, 16 Feb 2017 09:50:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.234.9 with HTTP; Thu, 16 Feb 2017 09:50:46 -0800 (PST) In-Reply-To: <098c01d28879$870afbb0$9520f310$@olddog.co.uk> References: <098c01d28879$870afbb0$9520f310$@olddog.co.uk> From: Spencer Dawkins at IETF Date: Thu, 16 Feb 2017 11:50:46 -0600 Message-ID: To: "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=94eb2c035690e0a6d50548a96f2f Archived-At: Cc: "Alvaro Retana \(aretana\)" , ioam@ietf.org, "tsv-ads@ietf.org" , ippm@ietf.org Subject: Re: [Ioam] IOAM Work Moving Forward X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:50:50 -0000 --94eb2c035690e0a6d50548a96f2f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Adrian, On Thu, Feb 16, 2017 at 11:24 AM, Adrian Farrel wrote= : > [...scurries to subscribe to another mailing list] > :-) > Can the TSV ADs comment on whether there is a plan to re-charter IPPM: > > - To be applicable to network layer and lower > > - To be scoped beyond "metrics" (such as path trace) > > - To attend to more detail than "characterize the network paths under tes= t > > and/or the performance of transport and application layer protocols on > > these paths" > Sure, I can comment (responsible AD for IPPM). We spoke with Brian and Bill (co-chairs for IPPM this morning), and Brian thinks IPPM would need to change about 15 percent of its charter to have IOPM in scope. If IPPM is willing to take this work on, I would, of course, want IPPM's charter to reflect this work. The discussions I've been involved with have been about the network layer, but not about anything lower. I could imagine path trace as a very basic metric, of course, but for the kind of details you're asking about, we've been talking about the relationship between IOAM and IPPM for less than 36 hours which overlapped a formal telechat, so I'd expect us to have a better-thought-out plan in the near future than we have today ... Spencer > Thanks, > > Adrian > > > > *From:* Ioam [mailto:ioam-bounces@ietf.org] *On Behalf Of *Alvaro Retana > (aretana) > *Sent:* 16 February 2017 16:58 > *To:* ioam@ietf.org > *Subject:* [Ioam] IOAM Work Moving Forward > > > > Hi! > > > > First of all, thank you all for the interest expressed in this topic and > the discussions about the charter. > > > > As you know, one of the discussions resulting from the Internal Review of > the proposed IOAM charter was whether the work was already within the ipp= m > WG scope or not. Over the last couple of days, I have dug deeper into th= at > question with the Transport ADs and the ippm WG Chairs, and our conclusio= n > is that there is significant overlap between the current ippm Charter and > the proposed IOAM work. Enough to justify moving the work forward in the > ippm WG and not splintering a related effort into a new WG. > > > > I have then stopped the chartering effort for a new WG. The proponents > will start discussions on the ippm list soon =E2=80=93 please join if you= =E2=80=99re not > there already. I will keep this list open for a couple more days. > > > > Clearly there is interest in developing this cross-area work in the IETF. > I hope that you will continue to participate as the topic progresses on t= he > ippm WG. It is important that this type of cross-area efforts be properl= y > discussed and that we don=E2=80=99t create more silos. I realize it took= us a > couple of tries to find what I think is a stable home for the IOAM work = =E2=80=93 I > know that the open discussion has only helped the overall process. > > > > Thanks! > > > > Alvaro. > --94eb2c035690e0a6d50548a96f2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Adrian,

On Thu, Feb 16, 2017 at 11:24 AM, Adrian Farrel <adrian@olddo= g.co.uk> wrote:

[...scurries to subscribe to another mailing= list]


:-)
=C2=A0

Can the TSV ADs comment on whether there is a plan to re-ch= arter IPPM:

- To be applicable to network layer and lower

- To be scoped beyond "metrics" (such as path trace)

- To attend to more detail than "characterize the networ= k paths under test

=C2=A0and/or the perfor= mance of transport and application layer protocols on =

<= span>=C2=A0=C2=A0these paths"


Sure, I can comment (responsible AD for IPPM).=C2=A0<= /div>

We spoke with Brian and Bill (co-chairs for IPPM t= his morning), and Brian thinks IPPM would need to change about 15 percent o= f its charter to have IOPM in scope.=C2=A0

If IPPM= is willing to take this work on, I would, of course, want IPPM's chart= er to reflect this work.

The discussions I've = been involved with have been about the network layer, but not about anythin= g lower.

I could imagine path trace as a very basi= c metric, of course, but for the kind of details you're asking about, w= e've been talking about the relationship between IOAM and IPPM for less= than 36 hours which overlapped a formal telechat, so I'd expect us to = have a better-thought-out plan in the near future than we have today ...

Spencer
=C2=A0

Thanks,

<= p class=3D"MsoNormal">Adrian=

=C2=A0

<= p class=3D"MsoNormal">From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Alvaro Ret= ana (aretana)
Sent: 16 February 2017 16:58
To: ioam@ietf.org
Subject= : [Ioam] IOAM Work Moving Forward

<= div>

=C2=A0

Hi!=

=C2=A0

First of all, thank you all for th= e interest expressed in this topic and the discussions about the charter.

=C2=A0

As you know, one of the discu= ssions resulting from the Internal Review of the proposed IOAM charter was = whether the work was already within the ippm WG scope or not.=C2=A0 Over th= e last couple of days, I have dug deeper into that question with the Transp= ort ADs and the ippm WG Chairs, and our conclusion is that there is signifi= cant overlap between the current ippm Charter and the proposed IOAM work.= =C2=A0 Enough to justify moving the work forward in the ippm WG and not spl= intering a related effort into a new WG.

=C2= =A0

I have then stopped the chartering effort for a new WG.=C2= =A0 The proponents will start discussions on the ippm list soon =E2=80=93 p= lease join if you=E2=80=99re not there already.=C2=A0 I will keep this list= open for a couple more days.

=C2=A0

Clearly there is interest in developing this cross-area work in the IETF.= =C2=A0 I hope that you will continue to participate as the topic progresses= on the ippm WG.=C2=A0 It is important that this type of cross-area efforts= be properly discussed and that we don=E2=80=99t create more silos.=C2=A0 I= realize it took us a couple of tries to find what I think is a stable home= for the IOAM work =E2=80=93 I know that the open discussion has only helpe= d the overall process.

=C2=A0

<= p class=3D"MsoNormal">Thank= s!

=C2=A0

Alvaro.


--94eb2c035690e0a6d50548a96f2f-- From nobody Thu Feb 16 11:15:17 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C681295A5 for ; Thu, 16 Feb 2017 11:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 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_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham 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 1ihu6tqhJ0fm for ; Thu, 16 Feb 2017 11:15:13 -0800 (PST) Received: from nm8-vm1.bullet.mail.gq1.yahoo.com (nm8-vm1.bullet.mail.gq1.yahoo.com [98.136.218.224]) (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 7FE6D12955E for ; Thu, 16 Feb 2017 11:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1487272512; bh=y9jfA9riuuziSaMfkHm4gHSJeWb9Ugo6E74JkdkfsyA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=bBtyhsEEBgBnp1cgui9mwHmRNvvPx6nyuANoicggkUef9sjG9HwV/qAy6UaTK6mpLFZu71x+ICVJ4SsRT9aQ/T6fQGmO+unlM/8Pk2gendRxxVG6OymadM3HgUqVeRgp1nnU1ITeCwHWjgB17xkeKJAHOtCYm30HEyfKf953Wu+SuWez+i5pVR9Gn2JaVsTkJx9yJ/2TBrr+A5wa3NE3t6Faa4DM/m0eaWgoLg3ykc51AzgVQAxGK4sU1Lz53lF4Eh5nNEukmPEpITNG2JFlpM4r4zyGDAEuNLxWdPnKTwjFnk8UKjI5i+dLn1pr9zACtFjaEF5MqGpREaFbm4bR0Q== Received: from [216.39.60.184] by nm8.bullet.mail.gq1.yahoo.com with NNFMP; 16 Feb 2017 19:15:12 -0000 Received: from [98.137.12.202] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 16 Feb 2017 19:15:12 -0000 Received: from [127.0.0.1] by omp1010.mail.gq1.yahoo.com with NNFMP; 16 Feb 2017 19:15:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 584108.17433.bm@omp1010.mail.gq1.yahoo.com X-YMail-OSG: l6NqxnUVM1lqeqXfiML8ti9zsfkI.pZVRrYPUJnaF_YDIB.oOnV7EZDaZ8qUW83 ZuUidFa9crdW6IJVJtDW18lVKYHNyTjXvJfMJBvkxJUO8I6WVuud3KZp9KC.W0M5Xp6_slALRLxU Ne7fclnJBYdTFi1RYKJKsO7pPnvSyWP4.Q5hwcaNOFVfULicr.KYEXVNTsrwR02nB.HDBrcKkg8K BikFmDsBbv7YT7mrCr.BGX6YPgElxpTqLfKWYddFIbg_HOZB7isdb_Pk3IqGqABifoxa_XyXRy9W 34J0cpyQ.plEEMerougge8kcbW8lFaBTSQSzudBTnZl66eTdjMaj5mgxzNfuJjUiCTNfid26Y.Xe gMugPpNtX0D4fQm4g.B.nALt263p9jO2EmolhZRYGTdaXXK4ooI1scPQFP6yoGQXF.WR.5IAsaQM Gh9vcmCz_KWNNBijBrXJm1rsKyD2f._u8lO8MlM2Pi4dOc.aYRx7rtC07KZbaKUsYjxdJ8tBE6Pv 2Q7KR7Lm3NWW1f20eILNSkS9oxTYrjYyjW5X9WwiLJO.7s6jT3UTcxlemjJ5j_kw- Received: from jws300069.mail.gq1.yahoo.com by sendmailws101b.mail.gq1.yahoo.com; Thu, 16 Feb 2017 19:15:12 +0000; 1487272512.206 Date: Thu, 16 Feb 2017 19:15:11 +0000 (UTC) From: To: "Frank Brockners (fbrockne)" , "ippm@ietf.org" Message-ID: <91884089.975471.1487272511971@mail.yahoo.com> In-Reply-To: References: <202517D0-A6CE-40D3-98BE-A2AFA8F83A19@trammell.ch> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_975470_640265054.1487272511971" Archived-At: Cc: Robert Hamilton , "ioam@ietf.org" , Michael Ackermann Subject: Re: [Ioam] [ippm] IOAM in IPPM X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:15:15 -0000 ------=_Part_975470_640265054.1487272511971 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Frank, As one of the authors of the PDM draft (draft-ietf-ippm-6man-pdm-option) that you discussed below. I find your work extremely interesting, as you know! I hope to see your work in IPPM. I can see that we may be able to collaborate and do quite interesting work in the future. Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ----- Original Message ----- From: Frank Brockners (fbrockne) To: "ippm@ietf.org" Cc: "ioam@ietf.org" Sent: Thursday, February 16, 2017 9:06 AM Subject: [ippm] IOAM in IPPM Dear IPPM WG, following the recommendation from the IPPM chairs (see also Brian's email below) as well as ADs involved (see also Alvaro's email below) the discussions on in-situ OAM (IOAM), we'd like the IPPM WG to consider adopting the IOAM work, especially the definition of formats and associated procedures for in-situ OAM, including mechanisms for capturing path and path-traversal related information as well as procedures to employ, configure, trigger, and export the embedded telemetry information. For this we'd suggest to adopt https://tools.ietf.org/html/draft-brockners-inband-oam-data-02 as a starting point for the work of IPPM on IOAM. Like Brian noted, IPPM WG already focusses on hybrid measurements (e.g. those enabled by the similar draft-ietf-ippm-6man-pdm-option), hence IOAM would be a natural complement and addition to that work and would benefit from all earlier work on metrics etc. Background on In-situ OAM: In-situ OAM provides real-time telemetry of individual data packets and flows. It is based on telemetry information which is embedded within live user traffic, where "live user traffic" means packets originated and terminated at the application layer. For more information on in-situ OAM, you could refer to the requirements draft we posted (draft-brockners-inband-oam-requirements-02), or check out the presentations we gave at IETF 96 and 97: https://www.ietf.org/proceedings/96/slides/slides-96-opsawg-8.pdf and https://www.ietf.org/proceedings/97/slides/slides-97-opsawg-in-situ-oam-00.PDF Appreciate your thoughts and support :-). Thanks, Frank -----Original Message----- From: Brian Trammell (IETF) [mailto:ietf@trammell.ch] Sent: Donnerstag, 16. Februar 2017 16:13 To: Frank Brockners (fbrockne) Subject: IOAM in IPPM Hi, Frank, As we discussed today, please do introduce your draft (draft-brockners-inband-oam-data-00) to the IPPM mailing list. Given our recent focus on hybrid measurements (e.g. those enabled by the similar draft-ietf-ippm-6man-pdm-option), I'd like to start a discussion there about considering the draft for adoption within IPPM. Thanks, cheers, Brian -----Original Message----- From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Alvaro Retana (aretana) Sent: Donnerstag, 16. Februar 2017 17:58 To: ioam@ietf.org Subject: [Ioam] IOAM Work Moving Forward Hi! First of all, thank you all for the interest expressed in this topic and the discussions about the charter. As you know, one of the discussions resulting from the Internal Review of the proposed IOAM charter was whether the work was already within the ippm WG scope or not. Over the last couple of days, I have dug deeper into that question with the Transport ADs and the ippm WG Chairs, and our conclusion is that there is significant overlap between the current ippm Charter and the proposed IOAM work. Enough to justify moving the work forward in the ippm WG and not splintering a related effort into a new WG. I have then stopped the chartering effort for a new WG. The proponents will start discussions on the ippm list soon - please join if you're not there already. I will keep this list open for a couple more days. Clearly there is interest in developing this cross-area work in the IETF. I hope that you will continue to participate as the topic progresses on the ippm WG. It is important that this type of cross-area efforts be properly discussed and that we don't create more silos. I realize it took us a couple of tries to find what I think is a stable home for the IOAM work - I know that the open discussion has only helped the overall process. Thanks! Alvaro. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm ------=_Part_975470_640265054.1487272511971 Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" Content-ID: <58d54cf4-f2d3-ba45-c214-7aca513f195c@yahoo.com> LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCkNvbW1lbnQ6IEdQR1Rvb2xzIC0gaHR0cHM6 Ly9ncGd0b29scy5vcmcNCg0KaVFJY0JBRUJDZ0FHQlFKWXBjR1VBQW9KRUlvU3Q3OEw2a2FqKzQ4 UC8yTVovaWI0Y2lYWkc4Vm5xTERkM3QyVA0KRWpEbUQ3cDhEdmFpdVZrcitIVTdiK2kxVGhrTnBt WkdsdVF0Y25nTlE2ZjRITUVlUkxGQUYyTTJQR1d1UVYyYw0KZFFQemlpaFIzQ3ZJSEFvS25JS2tL Y2d6NFJZSXRiRGEwRnVSM0I5amhhZVl0cUZLMFVCV2Vjb21jdTlJZkFpYw0KWHVUSWhsVmlNYVI3 UzEvNmdCdmVXODdxYm1TVVhOQVhrYVhSQ1ZmVll2dUc4d00rNzI3UUNGZVlhQUR1dmRNTg0KTnNu Q3YxakRCQzdFVVJxbFhUWVVwYXZrb0o0d3NpdU80S2l2VXNDWWpaSHU4OEZKMVZQL1hSa3ZlVDRl U0M3MQ0KT2R4aWpQOERNcVRJZzUxM0l1QkZJZmpBWHFUODV0YW5lUGxUN1JKNHRaVEpjNitMVTNj Zk5QLy9maWVxTjNKcg0KeldQOFZHSE1rbm10QTBBVjVQTU96Zk5lT0YvQkJLbkJjN21ZZmIydTRU RjJ5VnF3Wk5XY2ZiRy81MlNlMXNyWQ0KUGxlVWVFakNidzNYNUcyVDNEL1dWVXFacnJLU0s2Vzky bzRkRFNpZWdsVUhwYUwvMDdmQ2QzdERnWGpjRXZ3SQ0KN0ZGRkVCcmp2ZkRueWV6TFdYc005T3kw elY4aFVQM0svMlVHQlhHK2FzR29qby9xUkV6eldYbXRjQ1J1blVQcQ0KTk40SEdMZHdwQXNrcmVY Sm9DTVY2N1I3Z2VDd05kSUY3MGY4dDl2emdjeG40WUhhMmpTanQ4Y0ExKzNSL01TYQ0KaEw2R29a cC9YOXRoTGVCcEtlZHRNSllvbVBSU09zeFFUVGNBcE44T1ZKdUxYNTNZR3FQa2t6M3lQSDBWb3dH Vw0KNUQ4U3YvenQ0OEY2eGtIZlNlL1INCj1wNmpQDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0t LS0NCg== ------=_Part_975470_640265054.1487272511971-- From nobody Thu Feb 16 12:44:31 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60BB12969A; Thu, 16 Feb 2017 12:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 OwG8v-RN2cpf; Thu, 16 Feb 2017 12:44:22 -0800 (PST) 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 B6BC3129698; Thu, 16 Feb 2017 12:44:22 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v1GItfmX018321; Thu, 16 Feb 2017 13:58:00 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 28ng5fk1ev-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Feb 2017 13:57:59 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1GIvvjl014272; Thu, 16 Feb 2017 13:57:58 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1GIvn7O014109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Feb 2017 13:57:55 -0500 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 16 Feb 2017 18:57:32 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 v1GIvWgd026159; Thu, 16 Feb 2017 12:57:32 -0600 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 v1GIvQEO025872; Thu, 16 Feb 2017 12:57:26 -0600 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id F10CCEF831; Thu, 16 Feb 2017 13:57:25 -0500 (EST) 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, 16 Feb 2017 13:57:25 -0500 From: "MORTON, ALFRED C (AL)" To: "Frank Brockners (fbrockne)" , "ippm@ietf.org" Thread-Topic: IOAM in IPPM Thread-Index: AQHSiGc9cXzuyNyh40uXrix8UqmsmqFryByAgAAl5HA= Date: Thu, 16 Feb 2017 18:57:25 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF68C28D@njmtexg5.research.att.com> References: <202517D0-A6CE-40D3-98BE-A2AFA8F83A19@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.246.211] 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-02-16_14:, , 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-1612050000 definitions=main-1702160178 Archived-At: Cc: "ioam@ietf.org" Subject: Re: [Ioam] IOAM in IPPM X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:44:25 -0000 Hi Frank and numerous IOAM co-authors,=20 (with due respect to the charter discussion thread) When I saw the IOAM mailing list announced a few weeks back I looked-in and saw that there were several terms used to categorize this type of measurement method (in-situ, in-band, etc.). I planned to send a pointer to the definitions of categories=20 IPPM (and IETF) agreed when new methods began to appear, so I'll do it now: https://tools.ietf.org/html/rfc7799 >From the slides and the early sections of the draft, it appears what you propose here is a Hybrid Type I method (Augmentation or modification of the stream of interest). This proposal has much in common with the PDM Destination Option Header: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-= 07 which we knew about and classified in the RFC: https://tools.ietf.org/html/rfc7799#section-4.2 This method processes a user traffic stream and adds "fields which are dedicated to measurement" (the measurement intent is made clear in the title of this option). It may be useful to look at the points about MTU made in=20 section 4.2. It seems that the user traffic entering the=20 in-situ domain will need to leave significant space for=20 the various data format fields that would be added. If this topic has already been discussed, I hope you'll summarize it here for the IPPM crowd and/or provide good pointers. Another goal of Hybrid measurement is that modified traffic and unmodified traffic would be treated as the *same* class of traffic by the network. Otherwise, one advantage over=20 active measurement methods would be lost. We described this problem at the end of page 7 in RFC 7799:=20 Hybrid Methods of measurement that augment or modify packets of a "class C" in a host should produce results equivalent to Passive Methods of Measurement when hosts accessing and links transporting these packets along the path (other than those performing augmentation/modification) treat packets from both categories of methods (with and without the augmentation/modification) as the same "class C". The Passive Methods of Measurement represent the Ground Truth when comparing results between Passive and Hybrid Methods, and this comparison should be conducted to confirm the "class C" treatment. I wonder if you have considered this comparison/constraint yet during the IOAM format and measurement development. It would likely be useful to cover this topic on IPPM list. thanks and regards, Al > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Frank Brockners > (fbrockne) > Sent: Thursday, February 16, 2017 12:07 PM > To: ippm@ietf.org > Cc: ioam@ietf.org > Subject: [ippm] IOAM in IPPM >=20 > Dear IPPM WG, >=20 > following the recommendation from the IPPM chairs (see also Brian's > email below) as well as ADs involved (see also Alvaro's email below) the > discussions on in-situ OAM (IOAM), we'd like the IPPM WG to consider > adopting the IOAM work, especially the definition of formats and > associated procedures for in-situ OAM, including mechanisms for > capturing path and path-traversal related information as well as > procedures to employ, configure, trigger, and export the embedded > telemetry information. For this we'd suggest to adopt > https://tools.ietf.org/html/draft-brockners-inband-oam-data-02 as a > starting point for the work of IPPM on IOAM. Like Brian noted, IPPM WG > already focusses on hybrid measurements (e.g. those enabled by the > similar draft-ietf-ippm-6man-pdm-option), hence IOAM would be a natural > complement and addition to that work and would benefit from all earlier > work on metrics etc. >=20 > Background on In-situ OAM: In-situ OAM provides real-time telemetry of > individual data packets and flows. It is based on telemetry information > which is embedded within live user traffic, where "live user traffic" > means packets originated and terminated at the application layer. For > more information on in-situ OAM, you could refer to the requirements > draft we posted (draft-brockners-inband-oam-requirements-02), or check > out the presentations we gave at IETF 96 and 97: > https://www.ietf.org/proceedings/96/slides/slides-96-opsawg-8.pdf and > https://www.ietf.org/proceedings/97/slides/slides-97-opsawg-in-situ-oam- > 00.PDF >=20 > Appreciate your thoughts and support :-). >=20 > Thanks, Frank >=20 > -----Original Message----- > From: Brian Trammell (IETF) [mailto:ietf@trammell.ch] > Sent: Donnerstag, 16. Februar 2017 16:13 > To: Frank Brockners (fbrockne) > Subject: IOAM in IPPM >=20 > Hi, Frank, >=20 > As we discussed today, please do introduce your draft (draft-brockners- > inband-oam-data-00) to the IPPM mailing list. Given our recent focus on > hybrid measurements (e.g. those enabled by the similar draft-ietf-ippm- > 6man-pdm-option), I'd like to start a discussion there about considering > the draft for adoption within IPPM. >=20 > Thanks, cheers, >=20 > Brian >=20 > -----Original Message----- > From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Alvaro Retana > (aretana) > Sent: Donnerstag, 16. Februar 2017 17:58 > To: ioam@ietf.org > Subject: [Ioam] IOAM Work Moving Forward >=20 > Hi! >=20 > First of all, thank you all for the interest expressed in this topic and > the discussions about the charter. >=20 > As you know, one of the discussions resulting from the Internal Review > of the proposed IOAM charter was whether the work was already within the > ippm WG scope or not. Over the last couple of days, I have dug deeper > into that question with the Transport ADs and the ippm WG Chairs, and > our conclusion is that there is significant overlap between the current > ippm Charter and the proposed IOAM work. Enough to justify moving the > work forward in the ippm WG and not splintering a related effort into a > new WG. >=20 > I have then stopped the chartering effort for a new WG. The proponents > will start discussions on the ippm list soon - please join if you're not > there already. I will keep this list open for a couple more days. >=20 > Clearly there is interest in developing this cross-area work in the > IETF. I hope that you will continue to participate as the topic > progresses on the ippm WG. It is important that this type of cross-area > efforts be properly discussed and that we don't create more silos. I > realize it took us a couple of tries to find what I think is a stable > home for the IOAM work - I know that the open discussion has only helped > the overall process. >=20 > Thanks! >=20 > Alvaro. From nobody Fri Feb 17 03:14:14 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6771294F7; Fri, 17 Feb 2017 03:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.022 X-Spam-Level: X-Spam-Status: No, score=-14.022 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, RCVD_IN_SORBS_SPAM=0.5, 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 jESbDRF5TT86; Fri, 17 Feb 2017 03:14:11 -0800 (PST) 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 07B68129474; Fri, 17 Feb 2017 03:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9067; q=dns/txt; s=iport; t=1487330051; x=1488539651; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qO7E/KwEsTWxwUFWX0uiFlf9vv749kVfSDjuji99UGY=; b=C5jZfDokl1xpkigqPX1P6mFn359MugPKta8p7HI47aINNdwfgwH0QWFT mxlUiFb4bEKZhz0jryaFQy15VXz8j48Dqr3WUr7U9//bo0Zagc1ccNMCA wjTpMag8KGiM6x5iCrt3RFKz8vz/hTa1ZzsUV2v+idM+0KSBwfbzjasIS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQCQ2qZY/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygpYYEJB41akhCTJYIPggwshXYCghg/GAECAQEBAQEBAWIohHA?= =?us-ascii?q?BAQECAjo0CwwEAgEIEQQBAR8JBzIUCQgCBAENBQiJZA6yVYtYAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWGTIRvhBwKEQGGAQWcAAGGcIJaiEWCBIUXiXaHAYwaAR8?= =?us-ascii?q?4eAhRFRglhkR1AYg8gSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,171,1484006400"; d="scan'208";a="386906843" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2017 11:14:09 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v1HBE9h4031248 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Feb 2017 11:14:09 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 17 Feb 2017 05:14:08 -0600 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, 17 Feb 2017 05:14:08 -0600 From: "Frank Brockners (fbrockne)" To: "MORTON, ALFRED C (AL)" , "ippm@ietf.org" Thread-Topic: IOAM in IPPM Thread-Index: AQHSiGc9cXzuyNyh40uXrix8UqmsmqFryByAgAAl5HCAARoBAA== Date: Fri, 17 Feb 2017 11:14:08 +0000 Message-ID: References: <202517D0-A6CE-40D3-98BE-A2AFA8F83A19@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF68C28D@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF68C28D@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.55.190.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ioam@ietf.org" Subject: Re: [Ioam] IOAM in IPPM X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 11:14:13 -0000 Hi Al, thanks for your notes - please see inline (..FB:) -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Donnerstag, 16. Februar 2017 19:57 To: Frank Brockners (fbrockne) ; ippm@ietf.org Cc: ioam@ietf.org Subject: RE: IOAM in IPPM Hi Frank and numerous IOAM co-authors,=20 (with due respect to the charter discussion thread) When I saw the IOAM mailing list announced a few weeks back I looked-in and= saw that there were several terms used to categorize this type of measurem= ent method (in-situ, in-band, etc.). I planned to send a pointer to the definitions of categories IPPM (and IETF= ) agreed when new methods began to appear, so I'll do it now: https://tools= .ietf.org/html/rfc7799 >From the slides and the early sections of the draft, it appears what you pr= opose here is a Hybrid Type I method (Augmentation or modification of the s= tream of interest). This proposal has much in common with the PDM Destination Option Header: ht= tps://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-07 which we knew about and classified in the RFC: https://tools.ietf.org/html/rfc7799#section-4.2 This method processes a user traffic stream and adds "fields which are dedicated to measurement" (the measurement intent is made clear in the title of this option). ...FB: Yes. In-situ OAM would be "Hybrid OAM, Type 1" - we also mention thi= s explicitly in the requirements draft and refer to RFC7799, see section 1 = in https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02#p= age-3 It may be useful to look at the points about MTU made in section 4.2. It se= ems that the user traffic entering the in-situ domain will need to leave si= gnificant space for the various data format fields that would be added. If = this topic has already been discussed, I hope you'll summarize it here for = the IPPM crowd and/or provide good pointers. ...FB: In-situ OAM information requires space in the packet - and the in-si= tu OAM needs to have appropriate MTU support. A discussion on MTU and packe= t-size is found in the requirements draft in section 4.2, see https://tools= .ietf.org/html/draft-brockners-inband-oam-requirements-02#page-12 Another goal of Hybrid measurement is that modified traffic and unmodified = traffic would be treated as the *same* class of traffic by the network. Oth= erwise, one advantage over active measurement methods would be lost. We de= scribed this problem at the end of page 7 in RFC 7799:=20 Hybrid Methods of measurement that augment or modify packets of a "class C" in a host should produce results equivalent to Passive Methods of Measurement when hosts accessing and links transporting these packets along the path (other than those performing augmentation/modification) treat packets from both categories of methods (with and without the augmentation/modification) as the same "class C". The Passive Methods of Measurement represent the Ground Truth when comparing results between Passive and Hybrid Methods, and this comparison should be conducted to confirm the "class C" treatment. I wonder if you have considered this comparison/constraint yet during the I= OAM format and measurement development. It would likely be useful to cover = this topic on IPPM list. ...FB: This is a very worthwhile comment and has been briefly raised before= during discussions in OPSAWG at the last IETF. There is no easy answer to = the question: "Will a packet which is added in-situ OAM data be treated the= same as if it would not be added in-situ OAM data?", because it'll likely = depend on implementation details as well as the encapsulation used. Example= : There are implementations which forward packets differently in case an IP= v6 extension header is present in the packet - while not the case for all i= mplementations, some have that behavior. Now if IOAM would be added as an e= xtension header and it would be the only extension header present in the pa= cket, some implementations might indeed change their forwarding behavior. H= ence it is important to make sure that for the IOAM domain you indeed have = nodes which conform to the assumption that forwarding behavior will not cha= nge when IOAM data is added to the packet. What this leads to is probably another requirement we need to take into con= sideration - and that we should add to the requirements draft: E.g. somethi= ng like "The addition of IOAM data-records should not change the way packet= s are forwarded *within* the IOAM domain." Thoughts? Thanks, Frank thanks and regards, Al > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Frank Brockners > (fbrockne) > Sent: Thursday, February 16, 2017 12:07 PM > To: ippm@ietf.org > Cc: ioam@ietf.org > Subject: [ippm] IOAM in IPPM >=20 > Dear IPPM WG, >=20 > following the recommendation from the IPPM chairs (see also Brian's=20 > email below) as well as ADs involved (see also Alvaro's email below)=20 > the discussions on in-situ OAM (IOAM), we'd like the IPPM WG to=20 > consider adopting the IOAM work, especially the definition of formats=20 > and associated procedures for in-situ OAM, including mechanisms for=20 > capturing path and path-traversal related information as well as=20 > procedures to employ, configure, trigger, and export the embedded=20 > telemetry information. For this we'd suggest to adopt > https://tools.ietf.org/html/draft-brockners-inband-oam-data-02 as a=20 > starting point for the work of IPPM on IOAM. Like Brian noted, IPPM WG=20 > already focusses on hybrid measurements (e.g. those enabled by the=20 > similar draft-ietf-ippm-6man-pdm-option), hence IOAM would be a=20 > natural complement and addition to that work and would benefit from=20 > all earlier work on metrics etc. >=20 > Background on In-situ OAM: In-situ OAM provides real-time telemetry of=20 > individual data packets and flows. It is based on telemetry=20 > information which is embedded within live user traffic, where "live user = traffic" > means packets originated and terminated at the application layer. For=20 > more information on in-situ OAM, you could refer to the requirements=20 > draft we posted (draft-brockners-inband-oam-requirements-02), or check=20 > out the presentations we gave at IETF 96 and 97: > https://www.ietf.org/proceedings/96/slides/slides-96-opsawg-8.pdf and > https://www.ietf.org/proceedings/97/slides/slides-97-opsawg-in-situ-oa > m- > 00.PDF >=20 > Appreciate your thoughts and support :-). >=20 > Thanks, Frank >=20 > -----Original Message----- > From: Brian Trammell (IETF) [mailto:ietf@trammell.ch] > Sent: Donnerstag, 16. Februar 2017 16:13 > To: Frank Brockners (fbrockne) > Subject: IOAM in IPPM >=20 > Hi, Frank, >=20 > As we discussed today, please do introduce your draft=20 > (draft-brockners- > inband-oam-data-00) to the IPPM mailing list. Given our recent focus=20 > on hybrid measurements (e.g. those enabled by the similar=20 > draft-ietf-ippm- 6man-pdm-option), I'd like to start a discussion=20 > there about considering the draft for adoption within IPPM. >=20 > Thanks, cheers, >=20 > Brian >=20 > -----Original Message----- > From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Alvaro Retana > (aretana) > Sent: Donnerstag, 16. Februar 2017 17:58 > To: ioam@ietf.org > Subject: [Ioam] IOAM Work Moving Forward >=20 > Hi! >=20 > First of all, thank you all for the interest expressed in this topic=20 > and the discussions about the charter. >=20 > As you know, one of the discussions resulting from the Internal Review=20 > of the proposed IOAM charter was whether the work was already within=20 > the ippm WG scope or not. Over the last couple of days, I have dug=20 > deeper into that question with the Transport ADs and the ippm WG=20 > Chairs, and our conclusion is that there is significant overlap=20 > between the current ippm Charter and the proposed IOAM work. Enough=20 > to justify moving the work forward in the ippm WG and not splintering=20 > a related effort into a new WG. >=20 > I have then stopped the chartering effort for a new WG. The=20 > proponents will start discussions on the ippm list soon - please join=20 > if you're not there already. I will keep this list open for a couple mor= e days. >=20 > Clearly there is interest in developing this cross-area work in the=20 > IETF. I hope that you will continue to participate as the topic=20 > progresses on the ippm WG. It is important that this type of=20 > cross-area efforts be properly discussed and that we don't create more=20 > silos. I realize it took us a couple of tries to find what I think is=20 > a stable home for the IOAM work - I know that the open discussion has=20 > only helped the overall process. >=20 > Thanks! >=20 > Alvaro. From nobody Fri Feb 17 03:45:23 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA459129418; Fri, 17 Feb 2017 03:45:17 -0800 (PST) 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 eSjOv7XitFee; Fri, 17 Feb 2017 03:45:15 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991A112998C; Fri, 17 Feb 2017 03:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6672; q=dns/txt; s=iport; t=1487331915; x=1488541515; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=43kx1g25j/76xVGFqtcvYU+4O4AhyQF0RNfyIK6fdQk=; b=feGXsWzYwC8Rvoof0KpgyfEVUOFRv65rtxug4T3V8JkYdpSZS/99iu1h kGJ0z9/H5DxcTs/Qj80yVR8gzmdPejRml7y7ZFYpwOPteNwdCApviSDcO x7bGo+SW9OggLo9Q1fiZ9JKPLARQ5F2rMev14c3bb/aaXmXRgsYA15Q7b Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAQCZ4aZY/4ENJK1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNRYYEJB4NSigiSEJU0ggwfDYV2AhqBfz8YAQIBAQEBAQEBYii?= =?us-ascii?q?EcAEBAQICAQEhERUlCwwEAgEIEQQBAQMCIwMCAgIlCxQBCAgCBAENBQiJZA6wJ?= =?us-ascii?q?oIli1gBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQuFQYRvhCYRATMKJoI/gl8FlV2?= =?us-ascii?q?GIwGGcIJaiEWCBIUXiXaTGwEfOHgIURU9hkR1AYg8gSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,171,1484006400"; d="scan'208";a="209736824" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Feb 2017 11:45:14 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1HBjEdE030017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Feb 2017 11:45:14 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 17 Feb 2017 05:45:13 -0600 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, 17 Feb 2017 05:45:13 -0600 From: "Frank Brockners (fbrockne)" To: "nalini.elkins@insidethestack.com" , "ippm@ietf.org" Thread-Topic: [Ioam] [ippm] IOAM in IPPM Thread-Index: AQHSiGc9cXzuyNyh40uXrix8UqmsmqFryByAgACdp4CAAK/YMA== Date: Fri, 17 Feb 2017 11:45:13 +0000 Message-ID: References: <202517D0-A6CE-40D3-98BE-A2AFA8F83A19@trammell.ch> <91884089.975471.1487272511971@mail.yahoo.com> In-Reply-To: <91884089.975471.1487272511971@mail.yahoo.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.190.229] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Robert Hamilton , "ioam@ietf.org" , Michael Ackermann Subject: Re: [Ioam] [ippm] IOAM in IPPM X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 11:45:18 -0000 VGhhbmtzIE5hbGluaS4gTG9va2luZyBmb3J3YXJkIHRvIHRoZSBJT0FNIHdvcmsgaW4gSVBQTS4g RnJhbmsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElvYW0gW21haWx0bzpp b2FtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBuYWxpbmkuZWxraW5zQGluc2lkZXRo ZXN0YWNrLmNvbQ0KU2VudDogRG9ubmVyc3RhZywgMTYuIEZlYnJ1YXIgMjAxNyAyMDoxNQ0KVG86 IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxmYnJvY2tuZUBjaXNjby5jb20+OyBpcHBtQGll dGYub3JnDQpDYzogUm9iZXJ0IEhhbWlsdG9uIDxyaGFtaWx0b25AY2FzLm9yZz47IGlvYW1AaWV0 Zi5vcmc7IE1pY2hhZWwgQWNrZXJtYW5uIDxtYWNrZXJtYW5uQGJjYnNtLmNvbT4NClN1YmplY3Q6 IFJlOiBbSW9hbV0gW2lwcG1dIElPQU0gaW4gSVBQTQ0KDQpGcmFuaywNCg0KQXMgb25lIG9mIHRo ZSBhdXRob3JzIG9mIHRoZSBQRE0gZHJhZnQgKGRyYWZ0LWlldGYtaXBwbS02bWFuLXBkbS1vcHRp b24pIHRoYXQgeW91IGRpc2N1c3NlZCBiZWxvdy4gIEkgZmluZCB5b3VyIHdvcmsgZXh0cmVtZWx5 IGludGVyZXN0aW5nLCBhcyB5b3Uga25vdyENCg0KSSBob3BlIHRvIHNlZSB5b3VyIHdvcmsgaW4g SVBQTS4gIEkgY2FuIHNlZSB0aGF0IHdlIG1heSBiZSBhYmxlIHRvIGNvbGxhYm9yYXRlIGFuZCBk byBxdWl0ZSBpbnRlcmVzdGluZyB3b3JrIGluIHRoZSBmdXR1cmUuDQogVGhhbmtzLA0KDQpOYWxp bmkgRWxraW5zDQpJbnNpZGUgUHJvZHVjdHMsIEluYy4NCnd3dy5pbnNpZGV0aGVzdGFjay5jb20N Cig4MzEpIDY1OS04MzYwDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTog RnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSkgPGZicm9ja25lQGNpc2NvLmNvbT4NClRvOiAiaXBw bUBpZXRmLm9yZyIgPGlwcG1AaWV0Zi5vcmc+DQpDYzogImlvYW1AaWV0Zi5vcmciIDxpb2FtQGll dGYub3JnPg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE3IDk6MDYgQU0NClN1Ympl Y3Q6IFtpcHBtXSBJT0FNIGluIElQUE0NCg0KRGVhciBJUFBNIFdHLA0KDQpmb2xsb3dpbmcgdGhl IHJlY29tbWVuZGF0aW9uIGZyb20gdGhlIElQUE0gY2hhaXJzIChzZWUgYWxzbyBCcmlhbidzIGVt YWlsIGJlbG93KSBhcyB3ZWxsIGFzIEFEcyBpbnZvbHZlZCAoc2VlIGFsc28gQWx2YXJvJ3MgZW1h aWwgYmVsb3cpIHRoZSBkaXNjdXNzaW9ucyBvbiBpbi1zaXR1IE9BTSAoSU9BTSksIHdlJ2QgbGlr ZSB0aGUgSVBQTSBXRyB0byBjb25zaWRlciBhZG9wdGluZyB0aGUgSU9BTSB3b3JrLCBlc3BlY2lh bGx5IHRoZSBkZWZpbml0aW9uIG9mIGZvcm1hdHMgYW5kIGFzc29jaWF0ZWQgcHJvY2VkdXJlcyBm b3IgaW4tc2l0dSBPQU0sIGluY2x1ZGluZyBtZWNoYW5pc21zIGZvciBjYXB0dXJpbmcgcGF0aCBh bmQgcGF0aC10cmF2ZXJzYWwgcmVsYXRlZCBpbmZvcm1hdGlvbiBhcyB3ZWxsIGFzIHByb2NlZHVy ZXMgdG8gZW1wbG95LCBjb25maWd1cmUsIHRyaWdnZXIsIGFuZCBleHBvcnQgdGhlIGVtYmVkZGVk IHRlbGVtZXRyeSBpbmZvcm1hdGlvbi4gRm9yIHRoaXMgd2UnZCBzdWdnZXN0IHRvIGFkb3B0IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRh LTAyIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHRoZSB3b3JrIG9mIElQUE0gb24gSU9BTS4gTGlr ZSBCcmlhbiBub3RlZCwgSVBQTSBXRyBhbHJlYWR5IGZvY3Vzc2VzIG9uIGh5YnJpZCBtZWFzdXJl bWVudHMgKGUuZy4gdGhvc2UgZW5hYmxlZCBieSB0aGUgc2ltaWxhciBkcmFmdC1pZXRmLWlwcG0t Nm1hbi1wZG0tb3B0aW9uKSwgaGVuY2UgSU9BTSB3b3VsZCBiZSBhIG5hdHVyYWwgY29tcGxlbWVu dCBhbmQgYWRkaXRpb24gdG8gdGhhdCB3b3JrIGFuZCB3b3VsZCBiZW5lZml0IGZyb20gYWxsIGVh cmxpZXIgd29yayBvbiBtZXRyaWNzIGV0Yy4gDQoNCkJhY2tncm91bmQgb24gSW4tc2l0dSBPQU06 IEluLXNpdHUgT0FNIHByb3ZpZGVzIHJlYWwtdGltZSB0ZWxlbWV0cnkgb2YgaW5kaXZpZHVhbCBk YXRhIHBhY2tldHMgYW5kIGZsb3dzLiBJdCBpcyBiYXNlZCBvbiB0ZWxlbWV0cnkgaW5mb3JtYXRp b24gd2hpY2ggaXMgZW1iZWRkZWQgd2l0aGluIGxpdmUgdXNlciB0cmFmZmljLCB3aGVyZSAibGl2 ZSB1c2VyIHRyYWZmaWMiIG1lYW5zIHBhY2tldHMgb3JpZ2luYXRlZCBhbmQgdGVybWluYXRlZCBh dCB0aGUgYXBwbGljYXRpb24gbGF5ZXIuIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIGluLXNpdHUg T0FNLCB5b3UgY291bGQgcmVmZXIgdG8gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCB3ZSBwb3N0ZWQg KGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLXJlcXVpcmVtZW50cy0wMiksIG9yIGNoZWNrIG91 dCB0aGUgcHJlc2VudGF0aW9ucyB3ZSBnYXZlIGF0IElFVEYgOTYgYW5kIDk3OiBodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LW9wc2F3Zy04LnBkZiBh bmQgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRlcy05Ny1v cHNhd2ctaW4tc2l0dS1vYW0tMDAuUERGIA0KDQpBcHByZWNpYXRlIHlvdXIgdGhvdWdodHMgYW5k IHN1cHBvcnQgOi0pLg0KDQpUaGFua3MsIEZyYW5rDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBCcmlhbiBUcmFtbWVsbCAoSUVURikgW21haWx0bzppZXRmQHRyYW1tZWxsLmNo XSANClNlbnQ6IERvbm5lcnN0YWcsIDE2LiBGZWJydWFyIDIwMTcgMTY6MTMNClRvOiBGcmFuayBC cm9ja25lcnMgKGZicm9ja25lKSA8ZmJyb2NrbmVAY2lzY28uY29tPg0KU3ViamVjdDogSU9BTSBp biBJUFBNDQoNCkhpLCBGcmFuaywNCg0KQXMgd2UgZGlzY3Vzc2VkIHRvZGF5LCBwbGVhc2UgZG8g aW50cm9kdWNlIHlvdXIgZHJhZnQgKGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEtMDAp IHRvIHRoZSBJUFBNIG1haWxpbmcgbGlzdC4gR2l2ZW4gb3VyIHJlY2VudCBmb2N1cyBvbiBoeWJy aWQgbWVhc3VyZW1lbnRzIChlLmcuIHRob3NlIGVuYWJsZWQgYnkgdGhlIHNpbWlsYXIgZHJhZnQt aWV0Zi1pcHBtLTZtYW4tcGRtLW9wdGlvbiksIEknZCBsaWtlIHRvIHN0YXJ0IGEgZGlzY3Vzc2lv biB0aGVyZSBhYm91dCBjb25zaWRlcmluZyB0aGUgZHJhZnQgZm9yIGFkb3B0aW9uIHdpdGhpbiBJ UFBNLg0KDQpUaGFua3MsIGNoZWVycywNCg0KQnJpYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IElvYW0gW21haWx0bzppb2FtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKQ0KU2VudDogRG9ubmVyc3RhZywgMTYuIEZlYnJ1 YXIgMjAxNyAxNzo1OA0KVG86IGlvYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFtJb2FtXSBJT0FNIFdv cmsgTW92aW5nIEZvcndhcmQNCg0KSGkhDQoNCkZpcnN0IG9mIGFsbCwgdGhhbmsgeW91IGFsbCBm b3IgdGhlIGludGVyZXN0IGV4cHJlc3NlZCBpbiB0aGlzIHRvcGljIGFuZCB0aGUgZGlzY3Vzc2lv bnMgYWJvdXQgdGhlIGNoYXJ0ZXIuDQoNCkFzIHlvdSBrbm93LCBvbmUgb2YgdGhlIGRpc2N1c3Np b25zIHJlc3VsdGluZyBmcm9tIHRoZSBJbnRlcm5hbCBSZXZpZXcgb2YgdGhlIHByb3Bvc2VkIElP QU0gY2hhcnRlciB3YXMgd2hldGhlciB0aGUgd29yayB3YXMgYWxyZWFkeSB3aXRoaW4gdGhlIGlw cG0gV0cgc2NvcGUgb3Igbm90LiAgT3ZlciB0aGUgbGFzdCBjb3VwbGUgb2YgZGF5cywgSSBoYXZl IGR1ZyBkZWVwZXIgaW50byB0aGF0IHF1ZXN0aW9uIHdpdGggdGhlIFRyYW5zcG9ydCBBRHMgYW5k IHRoZSBpcHBtIFdHIENoYWlycywgYW5kIG91ciBjb25jbHVzaW9uIGlzIHRoYXQgdGhlcmUgaXMg c2lnbmlmaWNhbnQgb3ZlcmxhcCBiZXR3ZWVuIHRoZSBjdXJyZW50IGlwcG0gQ2hhcnRlciBhbmQg dGhlIHByb3Bvc2VkIElPQU0gd29yay4gIEVub3VnaCB0byBqdXN0aWZ5IG1vdmluZyB0aGUgd29y ayBmb3J3YXJkIGluIHRoZSBpcHBtIFdHIGFuZCBub3Qgc3BsaW50ZXJpbmcgYSByZWxhdGVkIGVm Zm9ydCBpbnRvIGEgbmV3IFdHLg0KDQpJIGhhdmUgdGhlbiBzdG9wcGVkIHRoZSBjaGFydGVyaW5n IGVmZm9ydCBmb3IgYSBuZXcgV0cuICBUaGUgcHJvcG9uZW50cyB3aWxsIHN0YXJ0IGRpc2N1c3Np b25zIG9uIHRoZSBpcHBtIGxpc3Qgc29vbiAtIHBsZWFzZSBqb2luIGlmIHlvdSdyZSBub3QgdGhl cmUgYWxyZWFkeS4gIEkgd2lsbCBrZWVwIHRoaXMgbGlzdCBvcGVuIGZvciBhIGNvdXBsZSBtb3Jl IGRheXMuDQoNCkNsZWFybHkgdGhlcmUgaXMgaW50ZXJlc3QgaW4gZGV2ZWxvcGluZyB0aGlzIGNy b3NzLWFyZWEgd29yayBpbiB0aGUgSUVURi4gIEkgaG9wZSB0aGF0IHlvdSB3aWxsIGNvbnRpbnVl IHRvIHBhcnRpY2lwYXRlIGFzIHRoZSB0b3BpYyBwcm9ncmVzc2VzIG9uIHRoZSBpcHBtIFdHLiAg SXQgaXMgaW1wb3J0YW50IHRoYXQgdGhpcyB0eXBlIG9mIGNyb3NzLWFyZWEgZWZmb3J0cyBiZSBw cm9wZXJseSBkaXNjdXNzZWQgYW5kIHRoYXQgd2UgZG9uJ3QgY3JlYXRlIG1vcmUgc2lsb3MuICBJ IHJlYWxpemUgaXQgdG9vayB1cyBhIGNvdXBsZSBvZiB0cmllcyB0byBmaW5kIHdoYXQgSSB0aGlu ayBpcyBhIHN0YWJsZSBob21lIGZvciB0aGUgSU9BTSB3b3JrIC0gSSBrbm93IHRoYXQgdGhlIG9w ZW4gZGlzY3Vzc2lvbiBoYXMgb25seSBoZWxwZWQgdGhlIG92ZXJhbGwgcHJvY2Vzcy4NCg0KVGhh bmtzIQ0KDQpBbHZhcm8uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0K From nobody Fri Feb 17 18:35:21 2017 Return-Path: X-Original-To: ioam@ietfa.amsl.com Delivered-To: ioam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46391129407; Fri, 17 Feb 2017 18:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 U_j8EO-E_vhO; Fri, 17 Feb 2017 18:35:15 -0800 (PST) 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 249F212941C; Fri, 17 Feb 2017 18:35:15 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v1I2ZBWn039845; Fri, 17 Feb 2017 21:35:11 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 28p9gg4sny-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Feb 2017 21:35:10 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1I2Z9Rt023873; Fri, 17 Feb 2017 21:35:09 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1I2Z3O0023850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Feb 2017 21:35:05 -0500 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sat, 18 Feb 2017 02:34:48 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 v1I2Ymke020213; Fri, 17 Feb 2017 20:34:48 -0600 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 v1I2Yfrd019963; Fri, 17 Feb 2017 20:34:41 -0600 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id 9F6FEE009C; Fri, 17 Feb 2017 21:34:40 -0500 (EST) 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, 17 Feb 2017 21:34:40 -0500 From: "MORTON, ALFRED C (AL)" To: "Frank Brockners (fbrockne)" , "ippm@ietf.org" Thread-Topic: IOAM in IPPM Thread-Index: AQHSiGc9cXzuyNyh40uXrix8UqmsmqFryByAgAAl5HCAARoBAIAA/nhA Date: Sat, 18 Feb 2017 02:34:39 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF68D7A0@njmtexg5.research.att.com> References: <202517D0-A6CE-40D3-98BE-A2AFA8F83A19@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF68C28D@njmtexg5.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.203.192] 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-02-18_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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702180023 Archived-At: Cc: "ioam@ietf.org" Subject: Re: [Ioam] IOAM in IPPM X-BeenThere: ioam@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion on In-Situ OAM List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 02:35:17 -0000 Hi Frank, one last reply, in-line [ACM] > -----Original Message----- > From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] > Sent: Friday, February 17, 2017 6:14 AM > To: MORTON, ALFRED C (AL); ippm@ietf.org > Cc: ioam@ietf.org > Subject: RE: IOAM in IPPM >=20 > Hi Al, >=20 > thanks for your notes - please see inline (..FB:) >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Donnerstag, 16. Februar 2017 19:57 > To: Frank Brockners (fbrockne) ; ippm@ietf.org > Cc: ioam@ietf.org > Subject: RE: IOAM in IPPM >=20 > Hi Frank and numerous IOAM co-authors, >=20 > (with due respect to the charter discussion thread) >=20 > When I saw the IOAM mailing list announced a few weeks back I looked-in > and saw that there were several terms used to categorize this type of > measurement method (in-situ, in-band, etc.). > I planned to send a pointer to the definitions of categories IPPM (and > IETF) agreed when new methods began to appear, so I'll do it now: > https://tools.ietf.org/html/rfc7799 >=20 > From the slides and the early sections of the draft, it appears what you > propose here is a Hybrid Type I method (Augmentation or modification of > the stream of interest). > This proposal has much in common with the PDM Destination Option Header: > https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-07 > which we knew about and classified in the RFC: > https://tools.ietf.org/html/rfc7799#section-4.2 >=20 > This method processes a user traffic stream and adds "fields which > are dedicated to measurement" (the measurement intent is made clear > in the title of this option). >=20 > ...FB: Yes. In-situ OAM would be "Hybrid OAM, Type 1" - we also mention > this explicitly in the requirements draft and refer to RFC7799, see > section 1 in https://tools.ietf.org/html/draft-brockners-inband-oam- > requirements-02#page-3 [ACM]=20 Thanks for the reference to IOAM requirements, I didn't see that one. Glad we're in agreement. >=20 > It may be useful to look at the points about MTU made in section 4.2. It > seems that the user traffic entering the in-situ domain will need to > leave significant space for the various data format fields that would be > added. If this topic has already been discussed, I hope you'll summarize > it here for the IPPM crowd and/or provide good pointers. >=20 > ...FB: In-situ OAM information requires space in the packet - and the > in-situ OAM needs to have appropriate MTU support. A discussion on MTU > and packet-size is found in the requirements draft in section 4.2, see > https://tools.ietf.org/html/draft-brockners-inband-oam-requirements- > 02#page-12 >=20 > Another goal of Hybrid measurement is that modified traffic and > unmodified traffic would be treated as the *same* class of traffic by > the network. Otherwise, one advantage over active measurement methods > would be lost. We described this problem at the end of page 7 in RFC > 7799: >=20 > Hybrid Methods of measurement that augment or modify packets of a > "class C" in a host should produce results equivalent to Passive > Methods of Measurement when hosts accessing and links transporting > these packets along the path (other than those performing > augmentation/modification) treat packets from both categories of > methods (with and without the augmentation/modification) as the > same "class C". The Passive Methods of Measurement represent the > Ground Truth when comparing results between Passive and Hybrid > Methods, and this comparison should be conducted to confirm the > "class C" treatment. >=20 > I wonder if you have considered this comparison/constraint yet during > the IOAM format and measurement development. It would likely be useful > to cover this topic on IPPM list. >=20 > ...FB: This is a very worthwhile comment and has been briefly raised > before during discussions in OPSAWG at the last IETF. There is no easy > answer to the question: "Will a packet which is added in-situ OAM data > be treated the same as if it would not be added in-situ OAM data?", > because it'll likely depend on implementation details as well as the > encapsulation used. Example: There are implementations which forward > packets differently in case an IPv6 extension header is present in the > packet - while not the case for all implementations, some have that > behavior. Now if IOAM would be added as an extension header and it would > be the only extension header present in the packet, some implementations > might indeed change their forwarding behavior. Hence it is important to > make sure that for the IOAM domain you indeed have nodes which conform > to the assumption that forwarding behavior will not change when IOAM > data is added to the packet. > What this leads to is probably another requirement we need to take into > consideration - and that we should add to the requirements draft: E.g. > something like "The addition of IOAM data-records should not change the > way packets are forwarded *within* the IOAM domain." >=20 > Thoughts? [ACM]=20 Yes, the additional requirement on the domain is needed We should also be able to specify one or more ways to=20 check that the requirement is met on a representative sample of paths across the domain. I suggest tests with two packet streams, one unmodified and another with incremental or pre-allocated insertion of the=20 IOAM data records. The set of metrics planned for measurement provide the basis for comparison, for example is the latency of the unmodified stream always less than an IOAM modified stream? We have to find a way to enable passive measurements on the=20 unmodified stream, but that's a detail to work-out later. Some of the other features of IOAM will be more challenging to test in this way, but let's give it some more thought... regards, Al >=20 > Thanks, Frank >=20 >=20 > thanks and regards, > Al >=20 > > -----Original Message----- > > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Frank Brockners > > (fbrockne) > > Sent: Thursday, February 16, 2017 12:07 PM > > To: ippm@ietf.org > > Cc: ioam@ietf.org > > Subject: [ippm] IOAM in IPPM > > > > Dear IPPM WG, > > > > following the recommendation from the IPPM chairs (see also Brian's > > email below) as well as ADs involved (see also Alvaro's email below) > > the discussions on in-situ OAM (IOAM), we'd like the IPPM WG to > > consider adopting the IOAM work, especially the definition of formats > > and associated procedures for in-situ OAM, including mechanisms for > > capturing path and path-traversal related information as well as > > procedures to employ, configure, trigger, and export the embedded > > telemetry information. For this we'd suggest to adopt > > https://tools.ietf.org/html/draft-brockners-inband-oam-data-02 as a > > starting point for the work of IPPM on IOAM. Like Brian noted, IPPM WG > > already focusses on hybrid measurements (e.g. those enabled by the > > similar draft-ietf-ippm-6man-pdm-option), hence IOAM would be a > > natural complement and addition to that work and would benefit from > > all earlier work on metrics etc. > > > > Background on In-situ OAM: In-situ OAM provides real-time telemetry of > > individual data packets and flows. It is based on telemetry > > information which is embedded within live user traffic, where "live > user traffic" > > means packets originated and terminated at the application layer. For > > more information on in-situ OAM, you could refer to the requirements > > draft we posted (draft-brockners-inband-oam-requirements-02), or check > > out the presentations we gave at IETF 96 and 97: > > https://www.ietf.org/proceedings/96/slides/slides-96-opsawg-8.pdf and > > https://www.ietf.org/proceedings/97/slides/slides-97-opsawg-in-situ-oa > > m- > > 00.PDF > > > > Appreciate your thoughts and support :-). > > > > Thanks, Frank > > > > -----Original Message----- > > From: Brian Trammell (IETF) [mailto:ietf@trammell.ch] > > Sent: Donnerstag, 16. Februar 2017 16:13 > > To: Frank Brockners (fbrockne) > > Subject: IOAM in IPPM > > > > Hi, Frank, > > > > As we discussed today, please do introduce your draft > > (draft-brockners- > > inband-oam-data-00) to the IPPM mailing list. Given our recent focus > > on hybrid measurements (e.g. those enabled by the similar > > draft-ietf-ippm- 6man-pdm-option), I'd like to start a discussion > > there about considering the draft for adoption within IPPM. > > > > Thanks, cheers, > > > > Brian > > > > -----Original Message----- > > From: Ioam [mailto:ioam-bounces@ietf.org] On Behalf Of Alvaro Retana > > (aretana) > > Sent: Donnerstag, 16. Februar 2017 17:58 > > To: ioam@ietf.org > > Subject: [Ioam] IOAM Work Moving Forward > > > > Hi! > > > > First of all, thank you all for the interest expressed in this topic > > and the discussions about the charter. > > > > As you know, one of the discussions resulting from the Internal Review > > of the proposed IOAM charter was whether the work was already within > > the ippm WG scope or not. Over the last couple of days, I have dug > > deeper into that question with the Transport ADs and the ippm WG > > Chairs, and our conclusion is that there is significant overlap > > between the current ippm Charter and the proposed IOAM work. Enough > > to justify moving the work forward in the ippm WG and not splintering > > a related effort into a new WG. > > > > I have then stopped the chartering effort for a new WG. The > > proponents will start discussions on the ippm list soon - please join > > if you're not there already. I will keep this list open for a couple > more days. > > > > Clearly there is interest in developing this cross-area work in the > > IETF. I hope that you will continue to participate as the topic > > progresses on the ippm WG. It is important that this type of > > cross-area efforts be properly discussed and that we don't create more > > silos. I realize it took us a couple of tries to find what I think is > > a stable home for the IOAM work - I know that the open discussion has > > only helped the overall process. > > > > Thanks! > > > > Alvaro.