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

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Stewart,

From: Stewart Bryant <[e-mail]>
Sent: Donnerstag, 27. Mai 2021 17:45
To: IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: Stewart Bryant <[e-mail]>
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 https://datatracker.ietf.org/doc/html/draft-brockners-opsawg-ioam-deployment-02#page-14 (will be refreshed soon).

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.

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?

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