Re: [ippm] Opsdir last call review of draft-ietf-ippm-ioam-direct-export-08

[Linda Dunbar <[e-mail]>]

Tal, 

Thank you very much for addressing my comments. 

Your update is very helpful. I am clearing the NITs. I think the document is READY for publication. 

Linda

-----Original Message-----
From: Tal Mizrahi <[e-mail]> 
Sent: Tuesday, June 14, 2022 1:49 AM
To: Linda Dunbar <[e-mail]>
Cc: [e-mail]; [e-mail]; IETF IPPM WG <[e-mail]>; Last Call <[e-mail]>; Martin Duke <[e-mail]>
Subject: Re: Opsdir last call review of draft-ietf-ippm-ioam-direct-export-08

Hi Linda,

Thanks for the comments.
Please see the response below.

Cheers,
Tal.

On Tue, Jun 14, 2022 at 6:12 AM Linda Dunbar via Datatracker <[e-mail]> wrote:
>
> Reviewer: Linda Dunbar
> Review result: Has Nits
>
> I have reviewed this document as part of the Ops area directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the Ops area directors.
> Document editors and WG chairs should treat these comments just like 
> any other last call comments.
>
> This document specifies an IOAM encoding (Direct Export Option) to 
> trigger IOAM data to be directly exported or locally aggregated 
> without being pushed into in-flight data packets.
>
> I think the document is READY with some nits:
> >From the operation point of view, can the "entity" that the IOAM is 
> >directed by
> DEX Option send an explicit request to all the nodes for the IOAM to 
> be exported to them? instead of asking the DEX encapsulating node to 
> encode the DEX in some data packet? If not, why? If yes, can you add a 
> comparison of those two approaches?

Something similar can be done by having the encapsulating node send a probe packet, as mentioned in the draft: "probe packets that are generated by the IOAM encapsulating node".
I suggest to add a slightly clearer explanation, as follows:

OLD:
      An IOAM encapsulating node configured to incorporate the DEX
      option encapsulates (possibly a subset of) the packets it forwards
      with the DEX option, and MAY export and/or collect the requested
      IOAM data immediately.  Only IOAM encapsulating nodes are allowed
      to add the DEX option type to a packet.
NEW:
      An IOAM encapsulating node configured to incorporate the DEX
      option encapsulates (possibly a subset of) the packets it forwards
      with the DEX option, and MAY export and/or collect the requested
      IOAM data immediately.  Only IOAM encapsulating nodes are allowed
      to add the DEX option type to a packet. An IOAM encapsulating node
      can generate probe packets that incorporate the DEX option. These
      probe packets can be generated periodically or on-demand (for example
      triggered by the management plane). The specification of such probe
      packets is outside the scope of this document.


>
> Thank you very much
> Linda Dunbar
>
>
>