Re: Martin Duke's Discuss on draft-ietf-6man-spring-srv6-oam-10: (with DISCUSS and COMMENT)

["Zafar Ali (zali)" <[e-mail]>]

Hi Martin,

Many thanks for your comments.
Please see [ZA] in-line.

Thanks

Regards … Zafar

From: Martin Duke via Datatracker <[e-mail]>
Reply-To: Martin Duke <[e-mail]>
Date: Monday, May 24, 2021 at 2:52 PM
To: The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Martin Duke's Discuss on draft-ietf-6man-spring-srv6-oam-10: (with DISCUSS and COMMENT)
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent-Date: Monday, May 24, 2021 at 2:52 PM

Martin Duke has entered the following ballot position for
draft-ietf-6man-spring-srv6-oam-10: 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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/



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

I would like to clarify that when the pseudocode says "Send the copied packet,
along with a timestamp to the OAM process for telemetry data collection and
export," that this "process" is colocated on the router, and that this process
further digests the data so that there is much less than 1 packet going out of
the box per O-bit packet processed.

If there is a case where each O-bit packet generates an entire packet going off
the router to a controller or external OAM process, there are extremely
unfortunate corner cases that are not sufficiently mitigated by rate-limiting.

[ZA] You are right. In fact, this point is explicit mentioned in section 3.3, bullet 5 (processing at Node N4) [https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-10#section-3.3].

“As part of processing
      the O-flag, it sends a timestamped copy of the packet to a local

      OAM process.
“
The rest of the exporting is based on local policy at the router.

To further clarify, we can add additional text in section 2.1.1 https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-10#section-2.1.1, as follows:


Current Text: Specification of the OAM process or the external controller
operations are beyond the scope of this document.

Proposed Text:  The OAM process is expected to be located on the routing node processing the packet,
   however the specification of the OAM process or the external controller
   operations are beyond the scope of this document.

Would the above diffs address your comment? Please advise

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

Thank you for addressing the TSVART comments (and to Magnus for the review)

I see that some of the contributors are in common, but this would appear to
have substantial overlap with
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/.

[ZA] Yes, IPPM DEX options do overlap with this functionality.
[ZA] This specification describes how to provide that functionality with a single bit in the SR Header.