Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)

[Giuseppe Fioccola <[e-mail]>]

Hi Alvaro,
Thanks for your review.
Please find my replies inline tagged as [GF].
I will publish a new version to address your comments.

Best Regards,

Giuseppe

-----Original Message-----
From: Alvaro Retana via Datatracker <[e-mail]> 
Sent: Monday, July 11, 2022 10:51 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Alvaro Retana's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-ippm-rfc8321bis-02: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

§7 ("Results of the Alternate Marking Experiment") makes several
recommendations about the use of one or two flag bits:

      One flag: packet loss measurement SHOULD be done as described in
      Section 3.1, while delay measurement MAY be done according to the
      single-marking method described in Section 3.2.1.  Mean delay
      (Section 3.2.1.1) is NOT RECOMMENDED since it implies more
      computational load.

      Two flags: packet loss measurement SHOULD be done as described in
      Section 3.1, while delay measurement SHOULD be done according to
      double-marking method Section 3.2.2.  In this case single-marking
      MAY also be used in combination with double-marking and the two
      approaches provide slightly different pieces of information that
      can be combined to have a more robust data set.

These recommendations are good, as they are the result of experimentation.
However, they don't provide any deployment or operational guidelines of when
is it ok to follow them and when it isn't.  For example, for the one flag case,
when it is ok to not measure packet loss as described in §3.1?  Why is the use
of that mechanism only recommended and not required?

I have the same questions for all the recommendations and optional indications
in the text above.  To clear this DISCUSS I expect deployment or operational
recommendations that can be used as implementation/deployment guidance.

[GF]: I agree. I can surely add more details. Regarding the packet loss measurement SHOULD can be replaced with MUST since it is the only option. Regarding the delay measurements, there are some considerations to do in order to provide guidelines, such as the number of flags available (If there is only one flag you have no choice) or the kind of information needed (double marking is more robust and allows to get more statistics) or software/hardware limitations (mean delay calculation is resource consuming).

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) I support Roman's DISCUSS position, and have a related question to this
text in §7.1 (Controlled Domain requirement):

   For security reasons, the Alternate Marking Method is RECOMMENDED
   only for controlled domains.

When is it ok to use the Alternate Marking Method in any other deployment? 
IOW, given the definition of a controlled domain earlier in this section, why
is its use only recommended and not required?

[I am not including this point as a DISCUSS because I expect it to be solved
when Roman's concern is addressed.]

[GF]: Indeed, I will replace that sentence with: "For security reasons, the Alternate Marking Method MUST only be applied in controlled domains."

(2) §7 says that a deployment "SHOULD also take into account how to handle and
recognize marked and unmarked traffic".   I don't see any interoperability need
to use an rfc2199 keyword.  IOW, s/SHOULD/should

[GF]: Ok, will do