Re: [ippm] Adoption call for IOAM deployment and integrity documents

"MORTON JR., AL" <acmorton@att.com> Mon, 16 August 2021 23:30 UTC

Return-Path: <acmorton@att.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFC03A21F8; Mon, 16 Aug 2021 16:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sbuvuh6f0GWW; Mon, 16 Aug 2021 16:30:39 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678553A21F7; Mon, 16 Aug 2021 16:30:39 -0700 (PDT)
Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 17GNFMX5002122; Mon, 16 Aug 2021 19:30:37 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 3afvmf6jpf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Aug 2021 19:30:36 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 17GNUWlV024378; Mon, 16 Aug 2021 19:30:36 -0400
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 17GNUSeF023931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Aug 2021 19:30:28 -0400
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 183B64009E68; Mon, 16 Aug 2021 23:30:28 +0000 (GMT)
Received: from GAALPA1MSGEX1AD.ITServices.sbc.com (unknown [135.50.89.99]) by zlp30485.vci.att.com (Service) with ESMTP id ADCC84009E75; Mon, 16 Aug 2021 23:30:27 +0000 (GMT)
Received: from GAALPA1MSGEX1CA.ITServices.sbc.com (135.50.89.108) by GAALPA1MSGEX1AD.ITServices.sbc.com (135.50.89.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Mon, 16 Aug 2021 19:30:27 -0400
Received: from GAALPA1MSGETA01.tmg.ad.att.com (144.160.249.126) by GAALPA1MSGEX1CA.ITServices.sbc.com (135.50.89.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14 via Frontend Transport; Mon, 16 Aug 2021 19:30:27 -0400
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.107) by edgeal1.exch.att.com (144.160.249.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Mon, 16 Aug 2021 19:30:19 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VNMkAOxqkjijCyLzQ69bXOPG7BqIlmGti/FVGHotHG1g6rVSlXoojI9hFC0rYvH5Jn2CEbGaN8bdVKyT0OLs+EXjx+A9g8lgSIOYZ8DJQYZD9D3B1PATYDYPndHHzfpFv2lJ5KoCnYwnF1WPycL+Hfe0brfNkw1WQuq2UrFhqn7gAADM3WYYaQ/61HYvPg+BcAPswmrG7erIssAhmeP+1CMkiqtuvoKNACs6+eiC5X3SX11OO+1WYDBKden+d4hVNNZL4Flv2gf2vqxs4MHqBNbfeLLi3efdCjNQvQwiGzBYve6J/mHJyqZHQcjcmM6kQ7lPyVtcwUFNU9YwTVaeig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4qhivpnHWYP2B7hDmijcWTO9nFp2ZXM3nv2d4iS0hvA=; b=KtrlsphhUF/haZqvUOjvwTgowiJ5a1p54NwGfkPVHxrE4GON09PhQ3Gm2iQpysi0EywL1UCLyUeaDQckDWZusyGTE7c5zVVziDxjazGGwc1WOR6Kn8evSqMVE/jW5N3UB1VJabyfe0ELYzmRquCd6moZ6PKGBnHZ6oF0jdAlRarjnmm7OqZrTXbe0UQsUZwUXB1mr6k3jtarScTpWwVLLgEUQmnygFBLWMwqbzQOBm0SxRNMMjo9nfg+915+vmBkm9uBM+7jW82eQ2ZF1sd3oK7xwKdQCiGfRrp43IVNXTolRIIcg7pfJdG2zXgpjluETIQsnb4ior6FV8Ma5ffizg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4qhivpnHWYP2B7hDmijcWTO9nFp2ZXM3nv2d4iS0hvA=; b=MjXQIp32z2G2vaByTIn1o9YlMf4COEUdmTUnzaaQwyC5sSogv8JW26LgMaaIwC7Wf4K7K446P2aG5LPznQcAbB5PD6caZOgUueHvh35Ufi/agx5AhC/+9hpr6dnZ1flaSIjYmjCFMJAgxUyJEYBbm6riDvvgVTA8ab5JNrsNBKQ=
Received: from SJ0PR02MB7853.namprd02.prod.outlook.com (2603:10b6:a03:32e::8) by BYAPR02MB4069.namprd02.prod.outlook.com (2603:10b6:a02:f9::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.19; Mon, 16 Aug 2021 23:30:17 +0000
Received: from SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::7c62:d778:c67f:2f46]) by SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::7c62:d778:c67f:2f46%9]) with mapi id 15.20.4415.023; Mon, 16 Aug 2021 23:30:17 +0000
From: "MORTON JR., AL" <acmorton@att.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>
Thread-Topic: [ippm] Adoption call for IOAM deployment and integrity documents
Thread-Index: AQHXiIS5YdUnAv9tKkSojs88htxN3at2tYKQ
Date: Mon, 16 Aug 2021 23:30:16 +0000
Message-ID: <SJ0PR02MB78531CFBA742399273C6BC93D3FD9@SJ0PR02MB7853.namprd02.prod.outlook.com>
References: <69C9F697-A970-41DD-B7EF-0C17204D57AA@apple.com>
In-Reply-To: <69C9F697-A970-41DD-B7EF-0C17204D57AA@apple.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=att.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2eaa29de-c678-4811-60b3-08d9610dce1d
x-ms-traffictypediagnostic: BYAPR02MB4069:
x-microsoft-antispam-prvs: <BYAPR02MB4069E217F71266EEAACFEE36D3FD9@BYAPR02MB4069.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Ne/QWnk1EgSaGMmgVnXrLcBOyYm2Ips1Gj5PBUV3kEu/Syok2pFe5Qt+tb+US9UQgYrSbfDar9JUk6ChhJ8L9BxdfZhjdCAeaesOgqY0bDO2AGmGJo2yNnGYUBC1hUUc+m5FGwexPXzPGOxnuFkXDolW7XbUKjoDkWXfydtfN3v08BHKdkOb+4xDkz7dYD2SgS1t58ylFpykW5MLOH7pDaDIgZDt5EnJlUEN8zIARgR5i1gZFM51uIP1Q1m6W4V7+vX0/qOcLHFQ/Jff3pwfybke2z0HVNj9KzUO4snF41zFge6B6ma0Uq3xFMURAjS88sf3ztGUQ4GksqVl2fFxzawGISmdPirmBQHBJZnpsb8HRKxsSqfcd5YH4CR1qoWHdUPog8XriAmp+Jxf4BPcsx9IMq0WQ4X5hj8O/fJsfoHdaQxO5LinU/Wz5aOXJr/et+taWmss0cXzAT0PV1orFXygCd4zmygohdyCUsbD9T0DD9POr0ysZ6nookydeAPcY8lxQqlqIedkdOJrNjvtcbxFG5AWnhCtTs8Hcnj2CSu9arjDeg+E4uGXLScT8IIN0MMRlMBZLbsNPXVgjzF1SpsjFjX8hALPuDjOO5taUr1JP12v4SsMp1w72Oc7gDV+jG0m/hg8X3pnJYIjuxX0CofTMmq1Qc7RpXAhJfqoWTIVjPchMpWpbgmPThF60FZ2EJ0JSrAfvxOiOuOmNgWYzn04Wjp9ia945koDCca67s4k7qVU6iQX7JoKARdmaG5LNPsDcdF5jCuklnWlVmqlE9BzC9KV/9X38/BXRyP2Px7ySuec1mZkjHUJSPejePAyduJ1Ww0A0bZKeK7Qy3M5VQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR02MB7853.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39860400002)(376002)(346002)(136003)(966005)(76116006)(38070700005)(55016002)(9686003)(71200400001)(110136005)(7696005)(66946007)(316002)(478600001)(52536014)(5660300002)(53546011)(66556008)(66476007)(66446008)(6506007)(64756008)(8936002)(86362001)(186003)(26005)(38100700002)(83380400001)(166002)(122000001)(82202003)(33656002)(8676002)(2906002)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: sFlYvONaFSM5ahOMp9ULnFcj3lBDko/etRU9zyVb5Hyqm5MdiA/wKrH8t7f8s6ZeskzrqmOftvJzN1vHUyl1FJ9KkViVf/Fk4KjiBQrOZqpUVCwQm8N9CmR9KRaLfzXY8Y0KaN8onF6P7RbOepGKvLqFlj+zs1+AVRa48rZ2GLyVThOdOmqVt5oVlr7Ey7jK6XTH4jR4N47A5o6jaxtPFfYEP9AC0xvY56Smjr7ymkADNAZnO+gEO+L/q4ptKd9oeEeXcO3umWapcg+yN6ITYTbxWBn9k6oZXS7btqnSeKt4Kdqp82osercOoJIaIqmLJlssL4RaSJ6xfn6mIfko3J4ByNyRA3MtLenJXlX5Zxjw3iT/1fgiMIpFmI0yHHvxJ2RPU2bOOraLub1WzxFRTSMr6rhiULF9bSfyCKtYMeQrzIStkJBLh+KtWtUryAFqOD6I9+aW05bbanSbP4dhVErbAYgHbc+28RZs6ZeDj/m8vEptOZgPZH0rFRx4XSczr6SS5zDMd96m2H4T14ZT+sVK3Ccfs177GybWUvjCoq9bCBoRBt1zYFIYGPUF9kwfyzqcjNxp+yxh8sYODABpdd+s6ljc4Eb4j7zyNhat01U6DjkhwLv4t4E2ws+fjjHuo/4SmmlL7+JIzB2ro4Ds7u5/+64uqarhXEmq3SYNtEDiYeg116IOjAOk/tX8EhAqarLwhAsrrB0sS5O9SrO7Db8uPWn/vujNPG6WsOEYfgAea+DQPytNgRNQB6VITUQ1YLAQLFEP/7OCzEH0478hrPS7z3NkEiA6HFrpCz7Rmfsw7vRCrkCKEp7ep2zbEiJGYuR5AWpWhCoj+DG/Sy4OjE/QTqMiHJOq3zTbIjguwz2JwK8BK/d9ChekMAmSrydN5ejQIJzwgfnosCWb5ZGz0psYMvhB7p6bcfiRSK5MUAbBXta7KLWAdNf2+873taxOglA4+9bH8iQlwXWJQ0n6PTgJjzUPqIiNNA9nHK60HrzfudWec+IH0Z3lGpMq8FIErLWqQ58JlDI/+0gGDAqrCi1RhYify9Y8BrbILmDahT6nyVD1PQZEgmXOOg0fvTVyvSxXZjFTi6iKjr32hJsutCqqQuE6HWoCOkF4uEt4IHySnIBRU8LIgk5cXoctATdCytT4avBKGSPPzqHnPA4It0gN1NK2rmnmNoe3FxbbapxKNZ7EXdl/IDk3WOEwmZP/3LxTS15Z0rXlAhMvUbLzuc7BCRXnsLuiP8bCcWfmH+G41LEAnA/KUGDZ8deeVBCj3a5dkbmxuE0Vzg7caalCDN1QSTZMIZ4D0evrLhRFL3D9e5PvSJLmKXWJQU6n8YG6
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_SJ0PR02MB78531CFBA742399273C6BC93D3FD9SJ0PR02MB7853namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR02MB7853.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2eaa29de-c678-4811-60b3-08d9610dce1d
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2021 23:30:16.8902 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kmZ/+tZiIg4wKFJlVOn/cQo5funpzaUK6wQhyKWhatWUMTgABetMGR/mLMFJcgS0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB4069
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: BB0793CB3502707E444EE7368FE4C94D3B2917476807105227E3218780FAA6B02
X-Proofpoint-ORIG-GUID: rdZ3ue8h2xA9p9i1Qja3Z-Ju23-neJ4E
X-Proofpoint-GUID: rdZ3ue8h2xA9p9i1Qja3Z-Ju23-neJ4E
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-16_09:2021-08-16, 2021-08-16 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 phishscore=0 clxscore=1015 malwarescore=0 mlxscore=0 priorityscore=1501 adultscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108160144
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/wNxHWd50ALdA2HRyXhC32qCvLf4>
Subject: Re: [ippm] Adoption call for IOAM deployment and integrity documents
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Aug 2021 23:30:45 -0000

Hi Tommy & Ian, Authors, and IPPM,

I took a look at the other draft the WG is considering.

TL;DR: I support adoption, and further development/review.

For In-situ OAM Deployment, the first sentence of the Abstract is the same as data Integrity, so same comment.

I note that this draft is intended as a BCP. It will be interesting to see if there is sufficient experience when the WG is reaching consensus to warrant BCP status, and we can leave this aspiration intact during WG adoption, IMO.

I appreciate that Section 4 (Types of IOAM) motivates deployment by describing use cases. But after introducing IOAM node roles, the draft should use that terminology in this section. Also, the ECMP acronym and load balancing got mixed together in an odd way. Last, "end-to-end" is used ambiguously in the Operations/Troubleshooting bullet:

Current:
   o  Per-hop tracing: OAM information about each IOAM node a packet
      traverses is collected and stored within the user data packet as
      the packet progresses through the IOAM domain.  Potential uses of
      IOAM per-hop tracing include:

      *  Optimization: Understand the different paths different packets
         traverse between a source and a sink in a network that uses
         load balancing such as Equal Cost Load Balancing (ECMP).  This
         information could be used to tune the algorithm for ECMP for
         optimized network resource usage.

      *  Operations/Troubleshooting: Understand which path a particular
         packet or set of packets take as well as what amount of jitter
         and delay different nodes in the path contribute to the overall
         end-to-end delay and jitter.

Suggest:
   o  Per-hop tracing: OAM information about each IOAM node a packet
      traverses is collected and stored within the user data packet as
      the packet progresses through the IOAM domain.  Potential uses of
      IOAM per-hop tracing include:

      *  Optimization: Understand the different paths different packets
|        traverse between a Encapsulating and a Decapsulating node in a network that uses
|        load balancing such as Equal Cost Multi-Path (ECMP).  This
         information could be used to tune the algorithm for ECMP for
         optimized network resource usage.

      *  Operations/Troubleshooting: Understand which path a particular
         packet or set of packets take as well as what amount of jitter
|        and delay different IOAM nodes in the path contribute to the overall
|        <source host to destination host ??> delay and jitter.


There seem to be many options for deployment, such as whether to use IOAM Direct Export in *Transit Nodes*, but it seems that some form of export is required at the edge nodes (Encap & Decap). In the context of this draft as a BCP, what (export) option is best for certain circumstances?

The term "best" only appears twice, on the first page. So please look for some circumstances where the best choice of options is clear, and call them out specifically, like "Pre-allocated Trace-Option is best-suited for software packet forwarder implementations." But
      "The operator has to ensure that the packet with the pre-allocated
      array that carries the IOAM Data-Fields does not exceed the MTU of
      any of the links in the IOAM domain."
The material provided in Section 7.3. IOAM Trace Option Types is closer to a BCP than other parts of the draft.

Regarding:
      ..."The operator
      has to ensure that the minimum MTU of any of the links in the IOAM
      domain is known to all IOAM transit nodes."
Each IOAM node knows the MTU of all its interconnecting links. So:
 - Isn't there some way the IOAM nodes can take the burden to discover and share the MTU info within the domain?
 - In a network domain with non-IOAM nodes and IOAM nodes, in what deployment scenario would the MTU-view of the IOAM nodes remain valid for the entire domain?

In 7.6 IOAM Active Mode:
(I'm sorry, I fell off the sled completely here.)

   The IOAM active mode flag indicates that a packet is an active OAM
   packet as opposed to regular user data traffic.  Active mode is
   expected to be used for active measurement using IOAM.  Example use-
   cases include:

   o  Endpoint detailed active measurement: Synthetic probe packets are
      sent between the source and destination, traversing the IOAM
      domain.  These probe packets include a Trace Option-Type (i.e.,
      either incremental or pre-allocated).
Are the source and destination outside the IOAM Domain?  Figure 1 of the flags draft says yes (?).
(But the packets seem to carry IOAM information/data into the domain, somehow.)

      Since the probe packets are
      sent between the endpoints, these packets are treated as data
      packets by the IOAM domain, and do not require special treatment
      at the IOAM layer.
So, the probe packets ARE encapsulated, like other data packets would be?
("do not require special treatment" is not clear to me.)

               The encapsulating node can choose to set the
      Active flag, providing an explicit indication that these probe
      packets are meant for telemetry collection.

Ok, but the flags draft says:
     The active flag indicates that a packet is used for active
     measurement.  An IOAM decapsulating node that receives a packet with
     the Active flag set in one of its Trace options must terminate the
     packet.
and then the Synthetic probe packets don't reach the intended destination,
beyond the IOAM domain ?? It would be good to make this clear(er).

In any case, I suggest to move the reference to the flags draft:
   For details on IOAM active mode, please refer to
   [I-D.ietf-ippm-ioam-flags].
very early in this section - don't place this reference in the last sentence.

hope this helps,
Al


From: ippm <ippm-bounces@ietf.org> On Behalf Of Tommy Pauly
Sent: Tuesday, August 3, 2021 12:29 PM
To: IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
Subject: [ippm] Adoption call for IOAM deployment and integrity documents

Hello IPPM,

As discussed in our meeting last week, we will be starting an adoption call for two IOAM-related documents that have been raised as important dependencies during the IESG review of IOAM-data.

This email begins a Working Group adoption call for two documents:

Integrity of In-situ OAM Data Fields
https://datatracker.ietf.org/doc/draft-brockners-ippm-ioam-data-integrity/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-brockners-ippm-ioam-data-integrity/__;!!BhdT!0Ny1D5V4maIuQ6qGnzMqhb2g1XeWhqAWW3MMMWLT5TI-730YRx2JHVbaSFNx$>
https://www.ietf.org/archive/id/draft-brockners-ippm-ioam-data-integrity-03.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-brockners-ippm-ioam-data-integrity-03.html__;!!BhdT!0Ny1D5V4maIuQ6qGnzMqhb2g1XeWhqAWW3MMMWLT5TI-730YRx2JHQVTAIy3$>

In-situ OAM Deployment
https://datatracker.ietf.org/doc/draft-brockners-opsawg-ioam-deployment/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-brockners-opsawg-ioam-deployment/__;!!BhdT!0Ny1D5V4maIuQ6qGnzMqhb2g1XeWhqAWW3MMMWLT5TI-730YRx2JHUSOBrbQ$>
https://datatracker.ietf.org/doc/html/draft-brockners-opsawg-ioam-deployment-03<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-brockners-opsawg-ioam-deployment-03__;!!BhdT!0Ny1D5V4maIuQ6qGnzMqhb2g1XeWhqAWW3MMMWLT5TI-730YRx2JHWwp9dBH$>

This call will last until Wednesday, August 18. Please reply to this email with your comments, and if you think these documents should be taken on by IPPM.

Best,
Tommy & Ian