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

From: Fabrice Theoleyre <[email-masked]>
Date: Tue, 22 Feb 2022 09:58:43 +0100

Dear colleagues, 

We plan to present this novel version during the next IETF meeting. If some of you could have a look at the draft before the next meeting, it would be fantastic!

Best regards,
Fabrice

> Le 17 janv. 2022 à 09:41, Fabrice Theoleyre <[email-masked]> a écrit :
> 
> Dear all, 
> 
> We have updated the draft (novel requirements section, consistency with the other RAW drafts, editorial modifications, etc.)
> 
> We would be grateful if you have any feedback for us. 
> 
> Best regards,
> Fabrice
> 
> 
> 
> 
>> Le 17 janv. 2022 à 09:39, [email-masked] a écrit :
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Reliable and Available Wireless WG of the IETF.
>> 
>>       Title           : Operations, Administration and Maintenance (OAM) features for RAW
>>       Authors         : Fabrice Theoleyre
>>                         Georgios Z. Papadopoulos
>>                         Greg Mirsky
>>                         Carlos J. Bernardos
>> 	Filename        : draft-ietf-raw-oam-support-03.txt
>> 	Pages           : 16
>> 	Date            : 2022-01-17
>> 
>> Abstract:
>>  Some critical applications may use a wireless infrastructure.
>>  However, wireless networks exhibit a bandwidth of several orders of
>>  magnitude lower than wired networks.  Besides, wireless transmissions
>>  are lossy by nature; the probability that a packet cannot be decoded
>>  correctly by the receiver may be quite high.  In these conditions,
>>  providing high reliability and a low delay is challenging.  This
>>  document lists the requirements of the Operation, Administration, and
>>  Maintenance (OAM) features are recommended to construct a predictable
>>  communication infrastructure on top of a collection of wireless
>>  segments.  This document describes the benefits, problems, and trade-
>>  offs for using OAM in wireless networks to achieve Service Level
>>  Objectives (SLO).
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-raw-oam-support/
>> 
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-raw-oam-support-03.html
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-raw-oam-support-03
>> 
>> 
>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>> 
>> 
>> -- 
>> RAW mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/raw
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 22 Feb 2022 19:02:38 -0800

Hi Fabrice,
thank you for the timely reminder. I believe that the draft is stronger
now. I have several questions that we might discuss:

   - 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?

   - 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.

   - 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?

I hope my notes make sense.

Regards,
Greg

On Tue, Feb 22, 2022 at 12:59 AM Fabrice Theoleyre <
[email-masked]> wrote:

> Dear colleagues,
>
> We plan to present this novel version during the next IETF meeting. If
> some of you could have a look at the draft before the next meeting, it
> would be fantastic!
>
> Best regards,
> Fabrice
>
>
>
> > We have updated the draft (novel requirements section, consistency with
> the other RAW drafts, editorial modifications, etc.)
> >

---

From: Fabrice Theoleyre <[email-masked]>
Date: Fri, 25 Feb 2022 09:27:32 +0100

Hi Greg,

Thanks for your questions.

> It is not clear what we are saying in the Terminology section with the following:

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?
> Further, in the same section, active measurement methods are discussed. I agree with the text but have a question about the following:
> 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":

Active OAM -> test packets
Passive OAM -> control packets (to report counter values to the source for instance)

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?

> I hope my notes make sense.

It doesn’t for sure, Greg, thank you !

Cheers,
Fabrice

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 26 Feb 2022 16:31:15 -0800

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 <
[email-masked]> wrote:

>    - It is not clear what we are saying in the Terminology section with
>    the following:
>
> More precisely, the controller (control plane) installs some rules, and
> the device applies in the data plane the rules on a per packet basis.
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?

> Passive OAM -> control packets (to report counter values to the source for
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.

> - 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.

---

From: Fabrice Theoleyre <[email-masked]>
Date: Sun, 27 Feb 2022 18:05:49 +0100

Hi Greg,

> Le 27 févr. 2022 à 01:31, Greg Mirsky <[email-masked]> a écrit :
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Greg,
> 
> 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?
+1

> 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.
FT>> Yes, for me, anything which is not a data packet is a control packet (routing, EB, etc.). Actually, that’s rather a control frame.  Shall I be more specific?

> GIM>> That is very interesting and, frankly, quite unexpected to me. I agree, we must make that explicitly clear in the document.

FT>> I will update the text, thank you for your comments Greg!

> It doesn’t for sure, Greg, thank you !

FT> Hum hum Hum….. Obviously, you should have read ”They do"! Sorry Greg!

Cheers,
Fabrice

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Mon, 28 Feb 2022 13:11:54 +0100

Hi guys,

Just jumping into the discussion to express my support also on making
explicit the distinction for active OAM on the dedicated vs piggybacking.

Thanks!

Carlos

On Sun, Feb 27, 2022 at 6:06 PM Fabrice Theoleyre <[email-masked]>
wrote:

>>    - The following text seems to indicate that "control" is being used
>>    as another term for "test":
>>
> FT>> Yes, for me, anything which is not a data packet is a control packet
> (routing, EB, etc.). Actually, that’s rather a control frame.  Shall I be
> more specific?
>