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

[Martin Duke <[e-mail]>]

Thanks, the DISCUSS is gone.

On Wed, Jun 2, 2021 at 9:45 AM Zafar Ali (zali) <[e-mail]> wrote:

> Hi Martin,
>
>
>
> Many thanks for the proposed text; much appreciated!
>
>
>
> We have posted rev-11 to include your proposed text:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-spring-srv6-oam-11.txt
>
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-11
>
>  (see also the attached email)
>
>
>
> Please advise if you have any further comment.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *Martin Duke <[e-mail]>
> *Date: *Tuesday, June 1, 2021 at 12:32 PM
> *To: *"Zafar Ali (zali)" <[e-mail]>
> *Cc: *The IESG <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject: *Re: Martin Duke's Discuss on
> draft-ietf-6man-spring-srv6-oam-10: (with DISCUSS and COMMENT)
>
>
>
> That helps a lot, thanks. I might add normative text to your proposed
> change
>
>
>
> The OAM process is expected to be located on the routing node processing
> the packet.
>
>    Although the specification of the OAM process or the external controller
>
>    operations are beyond the scope of this document, the OAM process
> SHOULD NOT be
>
>    topologically distant from the routing node, as this is likely to
> create significant security
>
>    and congestion issues."
>
>
>
> On Thu, May 27, 2021 at 12:06 PM Zafar Ali (zali) <[e-mail]> wrote:
>
> 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.
>
>
>
>
>
>
>
>