[OPSAWG]Re: draft-ietf-opsawg-ipfix-alt-mark review

[Giuseppe Fioccola <[e-mail]>]

Hi Benoit,
Thanks a lot for your detailed review.
Please see inline [GF]

Regards,

Giuseppe

From: [e-mail] <[e-mail]>
Sent: Friday, May 22, 2026 11:54 AM
To: [e-mail]
Cc: [e-mail]
Subject: draft-ietf-opsawg-ipfix-alt-mark review

Dear all,

Here is my review of raft-ietf-opsawg-ipfix-alt-mark review
The reason why it takes so long  to review this draft is that we can really review it in isolation.
First, it's based on RFC 9343 (which in turn is based on RFC9341 and RFC9342)

But most importantly, it's linked to
- draft-ietf-ippm-alt-mark-yang/<https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark-yang/> for the configuration
  Also I recently learned about draft-ietf-ippm-on-path-telemetry-yang/<https://datatracker.ietf.org/doc/draft-ietf-ippm-on-path-telemetry-yang/> which is yet another draft
  The key question to me is do I navigate/map from a YANG data model to an IPFIX IE
- Also, there is the draft-ietf-ippm-alt-mark-deployment<https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark-deployment/>, which is currently in WGLC in IPPM
  From the title, we can consider this draft as the equivalent of the RFC5706bis "Operational Considerations" section, right?
  I just finished this review and will be posting to the IPPM mailing list
[GF]: Yes, draft-ietf-ippm-alt-mark-deployment aims to provide guidance for the AltMark deployment and manageability aspects, similarly to RFC9378 on IOAM deployment.

I'll review the YANG modules next week and this might generate some more feedback in connection with draft-ietf-opsawg-ipfix-alt-mark or draft-ietf-ippm-alt-mark-deployment
[GF]: Thanks!

Here is my feedback on draft-ietf-opsawg-ipfix-alt-mark review

- the IPFIX IEs are actually really alternate marking specific (and even RFC9343 specifica), while the name are not

    +------------+---------------+-------------------------------------+

    | Element ID |     Name      |              Reference              |

    +------------+---------------+-------------------------------------+

    | TBD1       | FlowMonID     | [RFC-to-be],                        |

    |            |               | RFC9341, RFC9342, RFC9343           |

    +------------+---------------+-------------------------------------+

    | TBD2       | LossFlag      | [RFC-to-be],                        |

    |            |               | RFC9341, RFC9342, RFC9343           |

    +------------+---------------+-------------------------------------+

    | TBD3       | DelayFlag     | [RFC-to-be],                        |

    |            |               | RFC9341, RFC9342, RFC9343           |

    +------------+---------------+-------------------------------------+

    | TBD4       | PeriodNumber  | [RFC-to-be]                         |

    |            |               | [I-D.ietf-ippm-alt-mark-deployment] |

    +------------+---------------+-------------------------------------+
I believe we need IPFIX Information Elements such as

 altMarkIPv6LossFlag

 altMarkIPv6DelayFlag

 altMarkIPv6FlowMonID


[GF]: We could also generalize, considering extensions beyond IPv6. I would suggest:
  altMarkLossFlag
  altMarkDelayFlag
  altMarkFlowMonID

Actually, this is compulsory for AltMarkIPv6FlowMonID, because there is already the flowId (148)

  altMarkPeriodNumber is generic to the all Alt Mark, AFAICT. So we don't need IPv6

[GF]: Agree.

Btw note https://www.rfc-editor.org/rfc/rfc7012#section-2.3

   o  Names of Information Elements MUST start with lowercase letters.
Change it throughout the document.

[GF]: Ok! Thank you for pointing this out.

- "The NMS acts as Collector. The loss and delay metrics are computed on the NMS by comparing the packet counts and timestamps at each AltMark period, according to the AltMark technique [RFC9341] [RFC9342]."
This is true that RFC9343 does not have the timestamp to compute the delay on the router, and that the loss can only be computed on the collector. However, in line with RFC9951, Export of Delay Performance Metrics in IP Flow Information Export (IPFIX), asssuming we have the timestamp (like in RFC 9947), we would compute the delay (with the IPFIX IEs from RFC9951) directly in the router, with the benefit that linked to the monitored flow.
Do we need to adapt this sentence "The NMS acts as Collector. The loss and delay metrics are computed on the NMS by comparing the packet counts and timestamps at each AltMark period, according to the AltMark technique [RFC9341] [RFC9342]."

[GF]: I agree. I will modify this sentence accordingly and will further specify that there are actually two options for the computation.

- Should this previous remark (also) be addressed in ietf-ippm-alt-mark-deployment?
At first glance, it's about deployment choices.
I was not too sure which document to read first: draft-ietf-opsawg-ipfix-alt-mark,  ietf-ippm-alt-mark-deployment, or even the YANG module draft-ietf-ippm-alt-mark-yang, as all of these documents are connected.

[GF]: Yes, the different alternatives for the computation should be mentioned in draft-ietf-ippm-alt-mark-deployment. Also, in the Introduction of draft-ietf-ippm-alt-mark-deployment, I would add a paragraph to explain the relationship with all the other documents.

 ietf-ippm-alt-mark-deployment is an informative reference to draft-ietf-opsawg-ipfix-alt-mark, and vice-versa.
However, no reference from draft-ietf-ippm-alt-mark-yang to draft-ietf-opsawg-ipfix-alt-mark
To me, it's an important topic to be able to configure Alt Mark with YANG (draft-ietf-ippm-alt-mark-yang) and be able to map to IPFIX

[GF]: Ok, will add that reference.

- From the YANG tree, I see the flow-mon-id.

   +--rw altmark

      +--ro altmark-info

      |  +--ro timestamp-type?

      |  +--ro available-interface*          [if-name]

      |  |  +--ro if-name                    if:interface-ref

      +--rw altmark-profiles

         +--rw admin-config

         |  +--rw enabled?                   boolean

         +--rw altmark-profile*              [profile-name]

            +--rw profile-name               string

            +--rw filter

            |  +--rw filter-type?            altmark-filter-type

            |  +--rw ace-name?            -> /acl:acls/acl/aces/ace/name

            +--rw method-type?               altmark-method-type

            +--rw protocol-type?             altmark-protocol-type

            +--rw node-action                altmark-node-action

            +--rw measurement-period?        uint64

            +--rw flow-mon-id?               uint32

            +--rw measurement-mode?          altmark-measurement-mode

            +--rw enable-loss-measurement?   boolean

            +--rw enable-delay-measurement?  boolean
How do I know that it's linked to the newly named AltMarkIPv6FlowMonID?
Navigating between data models [RFC 3444] is costly. If we can help at the DM design time (in this case, IPFIX and YANG), this would be better.
Same for the measurement-period, is it mapped to AltMarkPeriodNumber? If yes, it should be the same name.

[GF]: I see your point. AltMarkIPv6FlowMonID and flow-mon-id should have the same name.
While, AltMarkPeriodNumber should have the same name of measurement-period-number from draft-ietf-ippm-on-path-telemetry-yang.

- "But, according to [RFC9343],  and any other AltMark protocol extensions,"
You can't speak for any other (future) AltMark protocol extensions, can you?
Proposal NEW: But, according to [RFC9343],  and its  AltMark protocol extensions

[GF]: Thanks for the suggestion!

- Question: RFC 9343, why enhanced in the following excerpt
3.1. <https://datatracker.ietf.org/doc/html/rfc9343#section-3.1> Data Fields Format<https://datatracker.ietf.org/doc/html/rfc9343#name-data-fields-format>

The following figure shows the data fields format for enhanced Alternate-Marking TLV (AltMark). This AltMark data can be encapsulated in the IPv6 Options Headers (Hop-by-Hop or Destination Option).

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                |  Option Type  |  Opt Data Len |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|              FlowMonID                |L|D|     Reserved      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I am confused because there are mutliple flavors of AltMark, and I recall one being called "enhanced" (IIRC, in the context of RFC 9947). However, "enhanced" is mentioned a single time in RFC9343. Is this a leftover? Worth an editorial errata?

[GF]: Yes, it is an editorial errata. Feel free to report it.

- Loss and Delay flags are one bit each, because they need to be Key Fields.
A boolean is exported as an octet. See https://datatracker.ietf.org/doc/html/rfc7011#section-6.1.5
I was thinking that instead of having a Boolean, we can export the entire byte, which improves performance at the IPFIX Metering Process side.

From RFC9343 section 3.1

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                   |  Option Type  |  Opt Data Len |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |              FlowMonID                |L|D|     Reserved      |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

However, the L and D are a little bit in a middle of nowhere in that structure.
Up to you to you to decide if it's an optimization to export the full byte, still stressing that the only one bit is valid, with the other bits to be ignored.
Note tht an extra IPFIX IE with the entire 4 bytes could make sense, when considered as a Key Field in its entierty or a non Key Field.
Take this comment or leave, just a suggestion.

[GF]: This is a good point. We will think about that.

- "The IPFIX Metering Process parameters, like the IPFIX Template Record, that generate the Flow Records must be reported to provide the complete measurement context."
Good, you use capitalization; use it too for Observation Point and Observation Domain
NEW: These nodes are all IPFIX Observation Points, while the IPFIX Observation Domain is the AltMark measurement domain.

[GF]: Ok.

- section 2.1

   The ipPayloadPacketSection(IE314) Information Element (IE) carries a

   series of n octets from the IP payload, starting sectionOffset(IE409)

   octets into the IP payload.

Missing "at"

At least, you want to stress that one option is for the IPFIX Metering Process to export the ipPayloadPacketSection

, along with the flow of interest

You must also describe how length you want to be able to catch the Hop-by-Hop or Destination Option IPv6 Options Headers.

I guess the ipPayloadPacketSection would be a key field, so that's a lot of Flow Records.

Maybe you want to stress it's not the best options.
In that same section, why do you speak about IPv4?

The IPv4 payload is that part of the packet that follows the IPv4

   header and any options.  The IPv6 payload is the rest of the packet

   following the 40-octet IPv6 header.  Note that any extension headers

   present are considered part of the payload.  The

   sectionExportedOctets(IE410) expresses how much data was observed,

   while the remainder is padding.


[GF]: I will revise that paragraph and highlight that the export of the ipPayloadPacketSection is not the best option and, for this reason, the draft introduces new IEs. Also, I will omit the part on IPv4.





- It's not to clear whether section 2.1 is the first monitoring options, while "new IPFIX

   entities for FlowMonID (TBD1), LossFlag (TBD2) and DelayFlag (TBD3)" is the second one, as described in section 2.2

Btw, why is section 2.2 with the second option called Flow Aggregation?


[GF]: Maybe the title of the sections could be changed to highlight the different approach.





- " According to Section 4 of [RFC7015] new Flow Keys may be derived from

   existing Flow Keys or "promoted" from specific non-key fields.



   Therefore FlowMonID, LossFlag and DelayFlag are considered Flow Key

   fields."



I believe you want to omit this, as it refers to Intermediate Mediation Process.

In this, you would just add new Key Fields to your Metering Process: FlowMondId, D, L


[GF]: Ok, will fix it.





- Editorial

OLD:  The following IPFIX entities

NEW:  The following IPFIX Information Elements


[GF]: Ok.

-

2.4.  Flow Measurements



   To calculate loss, the packet count can be based upon

   octetDeltaCount(IE1) or packetDeltaCount(IE2).


The loss of what? I reviewed section 3 and it's now a little bit clearer.
We speak about the loss of packets, between two Observation Points in the network (either source,
transit and unmarking node), following the forwarding plane, for the same PeriodNumber, right? This deserves some more explanation, as this single sentence is not sufficient.
Proposal: merging 2.4 and 3

[GF]: Yes, I will explain it better. The merge of sections 2.4 and 3 can also help for this purpose.

- section 2.4
While, to calculate delay, either flowStartSeconds(IE150), flowStartMilliseconds(IE152), flowStartMicroseconds(IE154) or flowStartNanoseconds(IE156), can be used depending on timestamp granularity requirements. It is also possible to use flowEndSeconds(IE151), flowEndMilliseconds(IE153), flowEndMicroseconds(IE155) or flowEndNanoseconds(IE157).

This assumes RFC 9947 (which include the timestamps), if you export from the routers
Important note: as a re-export from the controller, I would agree we don't need RFC 9947
And btw, you should reference RFC9951, Export of Delay Performance Metrics in IP Flow Information Export (IPFIX)

[GF]: It depends, because we can export the timestamps if the computation is done on the controller or the on-path delay if the computation is done directly on the router. I will explain it and add the references to RFC 9947 and RFC 9951.

- section 2.4
It is also defined the PeriodNumber (TBD4), which is needed for Alternate-Marking measurement correlation as per [I-D.ietf-ippm-alt-mark-deployment].
NEW: It also defines the PeriodNumber (TBD4)

[GF]: Ok.

Is this measurement-period-number from the YANG https://datatracker.ietf.org/doc/draft-ietf-ippm-on-path-telemetry-yang/ or measurement-period from the YANG in https://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-yang-02
We really need to think about the mapping of the data models
draft-ietf-ippm-on-path-telemetry-yang is not even a reference in draft-ietf-opsawg-ipfix-alt-mark, or should I read in sequence
    1. IPFIX alt marking
    2. the IPPM deployment
    3. YANG module for RFC9341/9342
    4. YANG module for on-path telemetry
It's a block of documents (who should progress together IMO) but the reading sequence is not obvious at this point in time.
I understand that the IPPM deployment document might be the overarching document but this is also the first one that is being WGLC.
I believe this is a potential problem. See (*)

[GF]: It is the measurement-period-number from draft-ietf-ippm-on-path-telemetry-yang. I will add cross-references between the same parameters in IPFIX and YANG. I will also mention in draft-ietf-ippm-alt-mark-deployment that it is the base document and it refers to the other documents.

- Flow Keys or not (too many repetitions/overlap)

OLD:
As specified in the previous sections, the Flow Keys used to define a flow are, at minimum, FlowMonID (TBD1), LossFlag (TBD2) and DelayFlag (TBD3). The traditional '5-tuple' Flow Key of source and destination IP address, source and destination transport port, and transport protocol can also be combined with the FlowMonID, LossFlag and DelayFlag.
NEW:
As specified in the previous sections, the Flow Keys used to define a flow are, at minimum, FlowMonID (TBD1), LossFlag (TBD2) and DelayFlag (TBD3). The traditional '5-tuple' Flow Key of source and destination IP address, source and destination transport port, and transport protocol can be selected as additonal Flow Keys, next the FlowMonID, LossFlag and DelayFlag.

OLD:
The AltMark Flows are defined separately for loss measurements and delay measurements. In particular, the flow for loss measurements can be aggregated using the 5-tuple, the FlowMonID and the LossFlag; while the flow for delay measurements can be aggregated using the 5-tuple, the FlowMonID and the DelayFlag.

NEW:
The AltMark Flows are defined separately for loss measurements and delay measurements. In particular, the flow for loss measurements can be identified the FlowMonID, the LossFlag (and potentially the extra Key Fields, if configured); while the flow for delay measurements can be identified the FlowMonID, the DelayFlag (and potentially the extra Key Fields, if configured)

[GF]: Ok, good suggestion.


...

OLD: The Flow Records are different for loss measurements and delay measurements. The flow record for loss measurements can be composed by the 5-tuple, the FlowMonID, the LossFlag, the PeriodNumber and the packetDeltaCount(IE2); while the flow record for delay measurements can be composed by the 5-tuple, the FlowMonID, the DelayFlag, the PeriodNumber and the flowStartMicroseconds(IE154), flowEndMicroseconds(IE155).

NEW: Together with the Key Fields, the Flow Records typically export the the PeriodNumber and the packetDeltaCount(IE2) for the loss measurement, while they typically export the he PeriodNumber and the flowStartMicroseconds(IE154), flowEndMicroseconds(IE155) for the delay measurements

[GF]: Ok, thanks.


-  flow record => Flow Record
throughout the document

[GF]: Ok.

-
The IPFIX Metering Process parameters, like the IPFIX Template Record, that generate the Flow Records must be reported to provide the complete measurement context.

Not clear whether you speak avbout the Metering Process parameters (like section 6.5 of RFC 5476), the single-marking methodology versus double-marking methodology (RFC 9341), or the normal Template Record used in IPFIX
If the latter (which I guess, you don't need this "must" as this is part of the IPFIX specs.
It the second, it should be done via YANG, no?

[GF]: I see. I will omit it.


-

4.1.  FlowMonID



      Name: FlowMonID



      Element ID: TBD1



      Description: The Flow Monitoring Identification (FlowMonID) is

      described in [RFC9343] and identifies the monitored flows with

      AltMark.  It is 20-bit unsigned integer encoded in the 20 least

      significant bits of the 32 bits, while the other bits are set to

      0.  It MUST be set pseudo-randomly by the source node or by a

      centralized controller.  It is to be noted that a new element has

      been defined since the flowid (IE148) can be used for other

      purposes and simultaneously with FlowMonID.


There is no point to speak about flowid (IE148) in the description of this IPFIX IE, especially if you change the FlowMonId name
"The Flow Monitoring Identification (FlowMonID) is  described in [RFC9343] and identifies the monitored flows with  AltMark." this is absolutely true.
(*) Somewhere in a document (not sure whether this one or ietf-ippm-alt-mark-deployment, you would have to explain that in IPFIX the monitored flows are identified by the values of the Key Fields. The flowMonID might or might not correspond to these values.

[GF]: I will delete the reference to flowid (IE148). It was just to avoid confusion.


- Your IPFIX IEs must use the Additional Information field to mention the relevant RFC, not the description field
See https://www.iana.org/assignments/ipfix/ipfix.xhtml

[GF]: Ok.


- RFC5706bis Operational Considerations section or is this ietf-ippm-alt-mark-deployment (which is an operational considerations document by itself)

[GF]: Ok, will add it.


Regards, Benoit