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

--- Begin Message ---

A new version of I-D, draft-ietf-6man-spring-srv6-oam-11.txt
has been successfully submitted by Zafar Ali and posted to the
IETF repository.

Name:		draft-ietf-6man-spring-srv6-oam
Revision:	11
Title:		Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)
Document date:	2021-06-02
Group:		6man
Pages:		23
URL:            https://www.ietf.org/archive/id/draft-ietf-6man-spring-srv6-oam-11.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-spring-srv6-oam-11

Abstract:
   This document describes how the existing IPv6 mechanisms for ping and
   traceroute can be used in an SRv6 network.  The document also
   specifies the OAM flag in the Segment Routing Header (SRH) for
   performing controllable and predictable flow sampling from segment
   endpoints.  In addition, the document describes how a centralized
   monitoring system performs a path continuity check between any nodes
   within an SRv6 domain.

                                                                                  


The IETF Secretariat

--- End Message ---