Re: [ippm] Issue with draft-ietf-ippm-ioam-data

Stewart Bryant <> Fri, 28 May 2021 09:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 266833A2141; Fri, 28 May 2021 02:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.239
X-Spam-Level: *
X-Spam-Status: No, score=1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BK9izxlYm9BG; Fri, 28 May 2021 02:05:11 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D30D3A2140; Fri, 28 May 2021 02:05:10 -0700 (PDT)
Received: by with SMTP id c3so2516689wrp.8; Fri, 28 May 2021 02:05:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=J1HEACqAi8rTzHWJsxSml2n+9AS4iUcR+8PL81p57Ak=; b=liqMo7abD0+iWcWlEBFOw8S/AFACchjVXEwqKXRGvjAnQ8tAxbG7Ltw207vBNO6iKe BpCxGRztdz/aW0Nv14KYxJYfgbTyDungmJWjqvGoDdC1wDcq/AAH95G5FOPGc2+ULU5i z+dynWn1e36Kp7UJ+L26cGguO2+G3CrOe4COPR9/P4lVKCcJbp91mU2oHs+9fg1KVIg/ lnkQlF3Uh9jVRq1gB5/xoW08TM+7zsiYIaKqO8PBfFN9sRNJdrRG1qCY+Ar+bOMPW2BZ 3oBZnjoOz/cjzAOSEFXBkUvrSPL+uiUo2OyT6du3xZqYvqjf0/U0vG8Doz4g7hFH6x8G GYqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=J1HEACqAi8rTzHWJsxSml2n+9AS4iUcR+8PL81p57Ak=; b=c1u/1EzQyt2hHPXVGc/W3i9CZ69N3com/L2UdYDC870u0yAGfFLVuWUYPARrL+qiEp exdghcclJBgssucm8TbwGkzPlhXAJWr953GwWZe/J2MzYU5CAuJDCShgkacc55uvGBDf 2BlI35rQ1SQtsVFUQzZc9aK5fQyNyezrfb8jzR0OXZWPQVkNwSgYQltfVJ+MSUxi3gR7 sQmdkde9M05Bu1OldWU6KyU2guoyKa9psCZ5f4roplzU6S8KDaEpMfAUWpnHkk66vzjt aQRjTsefex9bSdds20JDP4OOQUsfwYozOQWOYjn1sDIZmpY/qZPrA3SBi15xgChoUwMK w3dg==
X-Gm-Message-State: AOAM530oeVMzzeNpbqK7RWr0C0S2hnFdjlsTnsmiok7jc51a6PKBjhgI OynjzMF3zvR748DxAT7eAo4=
X-Google-Smtp-Source: ABdhPJxXiDQsuy4ir1EyKNADytFjTVzMBqdLKixxi1lph9DVDXBtUrtFvAT2dhG/+498rgWWc9rJng==
X-Received: by 2002:a5d:438c:: with SMTP id i12mr7349298wrq.44.1622192708144; Fri, 28 May 2021 02:05:08 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id y2sm15473311wmq.45.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 May 2021 02:05:07 -0700 (PDT)
From: Stewart Bryant <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_44F493B1-D487-43C8-B607-96A27A66B5AE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Fri, 28 May 2021 10:05:07 +0100
In-Reply-To: <>
Cc: Stewart Bryant <>, IESG <>, "" <>, "" <>, "" <>
To: "Frank Brockners (fbrockne)" <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [ippm] Issue with draft-ietf-ippm-ioam-data
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 May 2021 09:05:19 -0000

Hi Frank,

> On 27 May 2021, at 20:28, Frank Brockners (fbrockne) <> wrote:
> Hi Stewart,
> From: Stewart Bryant < <>> 
> Sent: Donnerstag, 27. Mai 2021 17:45
> To: IESG < <>>; <>; <>; <>
> Cc: Stewart Bryant < <>>
> Subject: Issue with draft-ietf-ippm-ioam-data
> I have been looking at "Data Fields for In-situ OAM" draft-ietf-ippm-ioam-data-12 as part of some work that we are doing in MPLS.
> The following came up in an MPLS design team meeting:
> In para 5.4 IOAM Trace Option-Types
> In the section on Incremental Trace-Option: there is the text:
> The IOAM
>       encapsulating node allocates space for the Incremental Trace
>       Option-Type. 
> One interpretation of this is that the ingress node preallocates space that the P nodes draw down on as needed to include their IOAM information.
> …FB: There are two IOAM Trace-Option Types defined. In case of the “Pre-allocated Trace-Option”, the encapsulating node pre-allocates space in the IOAM header that transit nodes will fill in their IOAM information. In case of “Incremental Trace-Option”, the encapsulating node won’t pre-allocate space for transit nodes but the transit nodes will allocate space and fill in their information at the same time. See also <> (will be refreshed soon).

SB> None, the less the draft I reference does need to be clarified before it becomes an RFC, because there were a number of opinions of what the text meant.

> Note that draft-ietf-ippm-ioam-data is focused on defining the data-fields for IOAM. BCP use of these data fields is discussed in the draft focused on IOAM deployment: draft-brockners-opsawg-ioam-deployment. The need for a more detailed discussion of the MTU aspects of IOAM came up in the recent IESG review – and those aspects will also be included in draft-brockners-opsawg-ioam-deployment moving forward.

SB> They clearly need discussing, but I am not sure the RFC we are talking about here should be published without either significant text on this important matter, or a normative reference to such a text. One reason to do this is to avoid late surprises with drafts that use the IOAM concept without studying its use in completely different data plane designs.

> In addition: The encapsulation of IOAM into a specific protocol is typically handled in a dedicated draft (e.g., draft-ietf-sfc-ioam-nsh covers the encapsulation of IOAM into NSH). As such, I’d expect that the aspects of encapsulating IOAM into MPLS would be handled by a dedicated draft. Such a draft would detail how IOAM Option-Types are encapsulated and even whether all IOAM data fields and Option-Types would apply to that particular encapsulation.
> Your message made me curious: I’m not aware of a draft that specifies IOAM encapsulation into MPLS – are you working on one?

SB> In MPLS we are looking at how we carry metadata, although I think it is more properly called auxiliary data as it provides essential assistance rather than clarifying description.

SB> One of the concepts that is on the table is to use pointers from the stack to auxiliary data to allow the specification of which AD element applies at a particular hop. This is particularly important in SR where you may you may not want to process all items at a particular hop or you may want to specify a parameter at a particular hop. Examples of the latter might be latency specification at a hop, partial IOAM, FRR advice etc. Fundamental to SR is moving the packet customisation from the control plane, or LSP construction to the packet itself.

SB> The advantage of using a pointer is that you go straight to the AD element you need without some deductive phase. The deductive phase is something that is always problematic in the use of implicit extension header selection, but if we can get to a explicit selection, there are many things that become much easier.

SB> The problem is of course not with variable length MD elements it is with *varying* length elements.

SB> Of course we are looking at a number of alternatives and pointers are just one approaches, but in discussions we came across this ambiguous wording.

SB> At a higher level, having a mid-node “randomly” insert data into a packet and expand its length is not something that we generally support in networking, and I am not sure we fully understand the consequences, or the limitations that it will impose on future development of the IP/MPLS network protocols. It is something that the wider community need to think very carefully about.

SB> I am of course sorry for raising this issue so late in the process, but this is the first time it has come to my attention,

Best regards


> Thanks, Frank
> Others thought that the the P nodes did an insertion into the packet by essentially moving all previous bytes to the “left” and adding in new information.
> This clearly needs to be clarified in the text.
> I also think the MTU text needs to be expanded because P routers now need to understand the MTU which was something that was not previously required.
> Best regards
> Stewart