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 <tal.mizrahi.phd@xxxxxxxxx>
Sent: Tuesday, June 14, 2022 1:49 AM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
Cc: ops-dir@xxxxxxxx; draft-ietf-ippm-ioam-direct-export.all@xxxxxxxx; IETF IPPM WG <ippm@xxxxxxxx>; Last Call <last-call@xxxxxxxx>; Martin Duke <martin.h.duke@xxxxxxxxx>
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 <noreply@xxxxxxxx> 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
>
>
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
