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

[Fabrice Theoleyre <[e-mail]>]

Hi Greg,


> Le 27 févr. 2022 à 01:31, Greg Mirsky <[e-mail]> 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 <[e-mail] <mailto:[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?
+1

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

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

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

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

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

Cheers,
Fabrice