Re: [Ioam] Internal WG Review: In-situ OAM (ioam)
"Alvaro Retana (aretana)" <aretana@cisco.com> Thu, 09 February 2017 22:38 UTC
Return-Path: <aretana@cisco.com>
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: A0AAAgBC7pxY/5RdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgm84KmGBCQeDUooIkWsfiAyNKoINHwEKgkKDNgIaglI/GAECAQEBAQEBAWIohGoCBAEBIUQHCxACAQgkFAcDAgICHwYLFBECBAENBYlcAxUOsAmCJSuHDw2EDgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhkyCBQiCYoJRgWYBATKCby6CMQWJDIxIhWQ6AYZuhwyEGQqBcY8KiCyCCYhfAR84fk8VPBEBhjB1AYdNgSGBDAEBAQ
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)" <aretana@cisco.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "ioam@ietf.org" <ioam@ietf.org>
Thread-Topic: Internal WG Review: In-situ OAM (ioam)
Thread-Index: AQHSgjmziLYbR6WLQk6B61NU2m1JJqFhgq0A///ULoA=
Date: Thu, 09 Feb 2017 22:38:45 +0000
Message-ID: <E23424A5-D78F-4680-B542-34CD6BC59862@cisco.com>
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: <https://mailarchive.ietf.org/arch/msg/ioam/DfBU2KIVM_oLwc4dgJCwxHDQV7w>
Cc: The IAB <iab@iab.org>, "iesg@ietf.org" <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 <ioam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ioam>, <mailto:ioam-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ioam/>
List-Post: <mailto:ioam@ietf.org>
List-Help: <mailto:ioam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ioam>, <mailto:ioam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Feb 2017 22:38:49 -0000
Stephen: Hi! I think tricky, but important. I’m cc’ing the list to get the answers there. To your second question. Yes, there clearly is an expectation on the outcome, if IPv6 is used as an encapsulating protocol. But that is not the only application. Thanks! Alvaro. On 2/9/17, 3:15 PM, "iesg on behalf of Stephen Farrell" <iesg-bounces@ietf.org<mailto:iesg-bounces@ietf.org> on behalf of stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>> wrote: Hiya, I have two possibly tricky questions about this: 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? 2) There is an ongoing and seemingly very hard to resolve discussion [1] on ietf@ietf.org<mailto:ietf@ietf.org> in which a draft related to this proposal has been quoted [2] as evidence on one side of the argument. I'm not clear that we should go ahead with this charter before we have established IETF consensus one way or another about what we think about [1] (by which I specifically mean the issue of headers being processed away from the endpoints). If I'm right that these are related (and it's possible I'm entirely wrong;-) then I guess depending on the outcome of [1] that'd either mean a short delay for this, or else a need for some major change and that risk would seem to me to justify not forging ahead with this just yet. So the question is: am I right that this proposal assumes one outcome of the discussion about header processing in [1]? Cheers, S. PS: I'm fine to ask these two questions in a ballot if that's better. But at the moment that'd likely be a BLOCK ballot so I wanted to check first if I'm off base, as happens now and then:-) [1] https://www.ietf.org/mail-archive/web/ietf/current/msg100960.html [2] https://www.ietf.org/mail-archive/web/ietf/current/msg101012.html On 08/02/17 18:32, IETF Secretariat 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 <aretana@cisco.com<mailto:aretana@cisco.com>> Routing Area Directors: Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>> Alvaro Retana <aretana@cisco.com<mailto:aretana@cisco.com>> Deborah Brungard <db3546@att.com<mailto:db3546@att.com>> Mailing list: Address: ioam@ietf.org<mailto: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. 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 Milestones:
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Alvaro Retana (aretana)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Carlos Pignataro (cpignata)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Stewart Bryant
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Carlos Pignataro (cpignata)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Alvaro Retana (aretana)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Stewart Bryant
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Mirja Kuehlewind (IETF)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Mirja Kuehlewind (IETF)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Frank Brockners (fbrockne)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Carlos Pignataro (cpignata)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Carlos Pignataro (cpignata)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Adrian Farrel
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Carlos Pignataro (cpignata)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Adrian Farrel
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Carlos Pignataro (cpignata)
- [Ioam] R: Internal WG Review: In-situ OAM (ioam) Fioccola Giuseppe
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Carlos Pignataro (cpignata)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Mirja Kuehlewind (IETF)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Spencer Dawkins at IETF
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Ram Krishnan
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Spencer Dawkins at IETF
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Ram Krishnan
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Joel M. Halpern
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Adrian Farrel
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Carlos Pignataro (cpignata)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Mirja Kuehlewind (IETF)
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Ram Krishnan
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Joe Clarke
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Stewart Bryant
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Adrian Farrel
- Re: [Ioam] Internal WG Review: In-situ OAM (ioam) Stewart Bryant