Re: [Raw] I-D Action: draft-ietf-raw-oam-support-03.txt

[Greg Mirsky <[e-mail]>]

Hi Fabrice,
thank you for your clarifications. Please find my follow-up notes in-lined
below under the GIM>> tag.
Please let me know if you'd like me to review any updates before the draft
submission cut-off deadline on February 7th.

Regards,
Greg

On Fri, Feb 25, 2022 at 12:27 AM Fabrice Theoleyre <
[e-mail]> wrote:

> Hi Greg,
>
> Thanks for your questions.
>
>
>    - It is not clear what we are saying in the Terminology section with
>    the following:
>
> The data plane takes the individual decision.
>
> Can you help me by giving an example?
>
>
> Example: deciding which time-frequency block / next hop to use for each
> packet.
>
> More precisely, the controller (control plane) installs some rules, and
> the device applies in the data plane the rules on a per packet basis.
> Does it make sense for you?
>
GIM>> Thank you, perfectly. Perhaps we can characterize this process as a
"local decision" or even extend it as follows:

On a per-node basis, the data plane applies rules and policies for each
packet. For example, selecting the time-frequency block or the next hop on
a packet-by-packet basis.

What do you think?

>
>    - Further, in the same section, active measurement methods are
>    discussed. I agree with the text but have a question about the following:
>
>       Active methods may implement
>
>       one of these two strategies:
>
>       -  In-band: control information follows the same path as the data
>
>          packets.  In other words, a failure in the data plane may
>
>          prevent the control information from reaching the destination
>
>          (e.g., end-device or controller).
>
>
>       -  out-of-band: control information is sent separately from the
>
>          data packets.  Thus, the behavior of control vs. data packets
>
>          may differ;
>
> For an active measurement method, what is the control information? Active
> OAM is differentiated from other measurement methods by its reliance on
> generated test packets. As stressed in the text, test packets must be
> in-band with the monitored data flow. I wonder if that text is useful for a
> reader.
>
>
> Yes, a test packet in active OAM corresponds to the control information.
> Thus, the distinction does not make sense for active OAM
> => to be explicited (i.e., out of band only for passive OAM)
>
>
>    - The following text seems to indicate that "control" is being used as
>    another term for "test":
>
>       piggybacking vs. dedicated control packets: control information
>
>       may be encapsulated in specific (dedicated) control packets.
>
> Though if I apply that assumption the result is not clear to me either:
>       piggybacking vs. dedicated test packets: test information
>       may be encapsulated in specific (dedicated) test packets.
>
> Am I missing something?
>
>
>
> Active OAM -> test packets
> Passive OAM -> control packets (to report counter values to the source for
> instance)
>
GIM>> I think that "control" is more often used in reference to packets
conveying routing information. I consider passive OAM to be part of the
management plane.

>
> But even withactive OAM (=test packets), I would probably make a
> distinction:
> - dedicated test packets, sent immediately
> - piggybacking: the test packet is encapsulated in another data packet
> (thus, buffered until a data packet has to be transmitted, and has enough
> space for the piggybacking)
>

> Is my reasoning correct? Does it make sense for you?
>
GIM>> That is very interesting and, frankly, quite unexpected to me. I
agree, we must make that explicitly clear in the document.

>
> I hope my notes make sense.
>
>
> It doesn’t for sure, Greg, thank you !
>
> Cheers,
> Fabrice
>
>
>
>