Re: [Tsv-art] Last Call: <draft-ietf-6man-spring-srv6-oam-09.txt> (Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)) to Proposed Standard

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 13 April 2021 09:09 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFDF3A0924; Tue, 13 Apr 2021 02:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14SYeaXvY75a; Tue, 13 Apr 2021 02:08:59 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60067.outbound.protection.outlook.com [40.107.6.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F147E3A091F; Tue, 13 Apr 2021 02:08:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QxPLG3i2RHYnJSwWUz3IwONbkcmtBs5SnRBFCDUI5gGxGkrRLZeHiYMY0nzvikuusw3uKko6It1AgJFWZF+usg5YuRQ5Asng670ETaTduoEFW5B3rngkk10zX79wNoKazTHYFlKYruDVFZEWKo5HpEkzwHsIaWN7Q8wsbAbx74N59/7uFJJ3RbxE4uBvYIl4OPIbRmriF8lUmc9Um21PWif3hbnA+BMwLnCKTPD/ZkcKU3LUy22HXQUCnBdnVGISKNOoQuEZ4Sfr8S02VVHb4gixwRE7T8yePm68/qkUwddHw+wmjRmcByXaJVogV1FHSDRUlLPRHAKWqxWwtlfPtw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4tyiYzr5y5iNzT3tkg1tegbEdBqcjGjDpcfw2A+t1qM=; b=E70L8IDTe/aCKkoNE1rZocsZUU9I3S975w880XqwRR6Uw7i2rWVRl/KtpYmPIIed847KpORvtJ3Fw+5FHJLZfeBHNxxUks5FfCFRAZeqtc6Lmn8M98RsUDIlD4HaHKO1gTwEwdKTYXvAOHENXmMyAsLga0q9bVeXilFhF1rrL7JW8Xp1Xb5NT6rWd7u1VKyuZYayUHge6P/EZa1GX3nEQSIcuL/og/9b8PLjCFIEZp9hVTa0lN0/X59gcBwZsX+9WtnEmlwHF6pP4MP7V2D+Qf+4rjZKxTBOJz5XWdmAxzDfraHjfAyyfnoqMjLZm+hQrCHgjPjz4JY1iWb0Sd5ZpA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4tyiYzr5y5iNzT3tkg1tegbEdBqcjGjDpcfw2A+t1qM=; b=GMjaAEyy8bWb54OYqs5cMN56sX684D+tdMikC7MbZSsCj6YDgk3xTUrbuj5Wy9rhkZHLku/lRNqbaH3EvIIdJcgPFM2rt6qdAACyG72P6iwvzLShCfzcAm9v4ZCSXBnfJodyykLQ/TVGHUAZohLVbFfH8F7psbgXsfADKRLhh28=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3817.eurprd07.prod.outlook.com (2603:10a6:7:86::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.13; Tue, 13 Apr 2021 09:08:55 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b08d:f37:b77b:2c8]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b08d:f37:b77b:2c8%6]) with mapi id 15.20.4042.015; Tue, 13 Apr 2021 09:08:55 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "last-call@ietf.org" <last-call@ietf.org>, "zali@cisco.com" <zali@cisco.com>
CC: "ipv6@ietf.org" <ipv6@ietf.org>, "draft-ietf-6man-spring-srv6-oam@ietf.org" <draft-ietf-6man-spring-srv6-oam@ietf.org>, "ot@cisco.com" <ot@cisco.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>
Thread-Topic: Last Call: <draft-ietf-6man-spring-srv6-oam-09.txt> (Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)) to Proposed Standard
Thread-Index: AQHXMEShutUealhv+USWTRFWaHT/Lg==
Date: Tue, 13 Apr 2021 09:08:55 +0000
Message-ID: <64891067484420644656d3477887629399670c74.camel@ericsson.com>
References: <161520275637.3336.12802912189924676386@ietfa.amsl.com> <HE1PR0702MB377255546E2D196AF27DF22D956B9@HE1PR0702MB3772.eurprd07.prod.outlook.com> <6BA86039-B1F7-4F33-80BD-8073169B11E3@cisco.com>
In-Reply-To: <6BA86039-B1F7-4F33-80BD-8073169B11E3@cisco.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.116.149]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 78dd85d9-7404-46f0-5a94-08d8fe5bc40f
x-ms-traffictypediagnostic: HE1PR0702MB3817:
x-microsoft-antispam-prvs: <HE1PR0702MB381786F313A4847E13BC2ACA954F9@HE1PR0702MB3817.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: GNuV/Rs8ynBdTt0tfxFVyYRIxaP4HNuv3GS7xMBA6yqEGdE+BbxZLbgBOkQlI3yH57K7GndGDOQImyDITyRUvTQx+McMFN+DnGUW1t5fuvis5rTEhXUJ62zhLYTtosNbTsY+q6HMcxjbrFmYtagVca4O74LkVwYiZeU0Jxcr3IgbGU3+vbNxCuVnNzzEl0uJI88kYzZkw1N+RJklXFJtVtQnxCdeF63ZobwrD/ZlfdnwttJFkkwCNHUjtXK09Y07ZWxG+Pz6FO4H/GYbAdARh+/FlXEbc1mD9CUxEiyKwkTrmvrMkGRiIdABS+vKQ6XTtjvP4Zn3rUhOwMNlqSd3Y5BTTVhs2zvhEGW7T4Wd1eBV1LZ9WjMXcHwqZL/oCMHm6GyPTAzKaVHj2fhIUs5mtfDzobZtt6M/bQd09xGaZJotU8AuZSlINCo5GlV04fJvIVSSsgbBQ8fTNq1ZMW+DKLC9Y3Cr2+RnwYOZ/69qcZXu84YH92uhgubfcSj9YPkj5qSA0Ai9HAnCTf9p9AFdCYE8zgHIsFDpcedjqB3Tnhj0a+T+7XyWFl4b7MWPbgmAvQIFXX+9RHVwNiHYT3gjiXzj1U7qHo2RQhQADOGS5qR4x1ep2Is8H0KNaP1mIdWs2widPdcCItl6Nad+n99vfaN4mSc4SYWYo3vTPvRnFDSW8/oV+7WT7xApD8L2sxlptCOu314vjDRp6+5qoPmbspBGc/gv8JNxRJnQt43Ny/bZKOZkDe1K48ca2V7HNl8Q
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(346002)(376002)(396003)(136003)(5660300002)(2906002)(38100700002)(110136005)(6486002)(54906003)(53546011)(6506007)(8676002)(8936002)(26005)(122000001)(316002)(186003)(4326008)(76116006)(66446008)(966005)(6512007)(66574015)(478600001)(99936003)(66616009)(66946007)(66556008)(86362001)(66476007)(64756008)(2616005)(36756003)(83380400001)(44832011)(71200400001)(99106002)(554374003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?RjR3ZUlGWHM0UkVZcm53Y2VaV1Joak1tcFpTbmFnTFZCcTVUQjB5dE5kS3N3?= =?utf-8?B?RlhNRzk3WnhvSlZMaVduVFZsMzUxcXlZZUthdnI1VHZqTFB5cTIzeS81YjBs?= =?utf-8?B?a01IWEpvaHFwemFyQW5mUFdOSDY3MENsMkhJREE1WjhPcDJUdE4rakNJVC9V?= =?utf-8?B?RGIrSzBESWRTME5yNlVmWk4wT0lHeXpOdTBOS3BlcHI5VitpQXdFZ0c4emFB?= =?utf-8?B?M05GV0pjVVdYamd3TjNSb1g0Y0JxK1FMZ1NiTzZZa1dlZjBxbG5seGQxb3BH?= =?utf-8?B?NDVxOEk1cXVaZVQ3eVdmTzdtZmtBSzNmLzUyRFlKUDFrc0YwNEo1Zkx4NURV?= =?utf-8?B?TkJrQ0VpdkN0bytEdXFtalIzVkRJM1BwZFVJbGxSVThHRTYvMU56RE1VdGdT?= =?utf-8?B?bFA4VjBSQkRlLzg1NmRZY0x3QnVSNDFoNXJncDNwZE1jVnF0NTZBNWlEekN6?= =?utf-8?B?VVdXbVZFR0lCS2hTZkp6MnZUSFhOUlV0eVErL0oyUXBPQ1dmOStOSW5kY2tH?= =?utf-8?B?cjlzQ3JsM0NNeUdwTTZsME5pd2FtN1hnV3luRzlVQkhLVkx1eDF2TnBMUVBR?= =?utf-8?B?b2dOVG95bVBsaGVoTk15dE9BUkliam9XWjJRMWJOcnNUczB3VjZsTCtRTnRm?= =?utf-8?B?am85Ums2aVFxT1dzVjRFQnVhR3ZvRXNSc1M0NTBKT1pBV3Bvd3M4VXp1R0FF?= =?utf-8?B?Sm0rbXJHWGVoRGl1d2F6aFhGUmpQR2w5S2NUMnNUVjViN3UrbFFGUGgzbWRN?= =?utf-8?B?UjZ2SkxCWlFqWGlydC9SazlWNXlEOERKTlluOUxLTDVYUTVUNHFWcmlpdkpt?= =?utf-8?B?MjBia25EVFpWOXpKZjVEL1hXREFkRjZPb2pSaEd5ZzA3WXNGbW1HYmhwd0VM?= =?utf-8?B?cHR0OHkwWFFraGQ5MW1kdG1KZnI1VVQzVHM0WkE5K3BlaWtTZmpTUkROeWlu?= =?utf-8?B?UXVqSHBaeXB5aFo4anc0OURFaGZjL28rSDZkakErVFM3S1Y1MFV3NVZOcFMz?= =?utf-8?B?VXQ0QnZUQm1RZnlUeG5jU3kyT0hhdTlHVGY0TXFSbFBGMDlzSTFkaWpqOEtn?= =?utf-8?B?ZnNhemhKNEVpajN6Y24rT3dmUjgzczl3T1hRbTJNaUlrWnhYQ293aDhVck5p?= =?utf-8?B?QjQxWnBodHgrSS9SYjV1MUFucHNBeEJQY2lhRlRJaTFBdDFMMVNNV3JoeVY3?= =?utf-8?B?bzhLV1VDY2pkTFNoNjE0ekt6R0ZlSXZ3ZmdnVmY1QmhvaFEwWWpkSmZDbld3?= =?utf-8?B?c2pqR1JNNVJqNFRtT3diYm05TDJtMDVHLzR1Q2VFWEt1NjBsNGwwVzJ2b0t1?= =?utf-8?B?clVmOFlBall4SkFxRmlITngxdUxXVEFlamRKT1g5WHIvWUY4SXA4T2dPWUJ5?= =?utf-8?B?cUZVdW50RDE2OTJPbkJxVUJnbnBKdHJ2RVZiUUo2MVlNbXRVVjljZGdVbllK?= =?utf-8?B?NzlpS3hQKzJieTVHOEpLMlB6Q2FpOGc2L3VkVWRaWFhmLzk0THRzK1RpRVA1?= =?utf-8?B?MElqTmcrZHp5QzhrdDJNT3Nsb1krQk5ESEZnR1FiVUZFQUZxeVR6bDF3SzBR?= =?utf-8?B?cE4rbWFIaWxtdkF3d0E1Z0doc2ExT0hRL3JHSXg5R1lib0tzY1ZEaXhRZmpP?= =?utf-8?B?aVZNa09KdkU0UjBVQUxSTGd3dThyVEtlbDYrcVFzNzFMZWNZR3lUVVNtYnFr?= =?utf-8?B?dy9GUDQvT2o2cDlnV1R0NG02VHFZbkR0T3JHMXNMcW1SbHFQdTBUcW5PYXZW?= =?utf-8?Q?UGyNGDBRTT/al9iXdaT0IdZgy+tHsaoqspntM9X?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-ZA1a6Gyv9p1MNwAKYiX7"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 78dd85d9-7404-46f0-5a94-08d8fe5bc40f
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2021 09:08:55.6115 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: INycasSG7w3t34P2GF3nOHOQx/ZWkl5JM1n1q024NsjKTMv5Lt04yrW+jYA+T/NKtOldcCEIklHdw2gQE4W3Gw1k91R2T4XvYJNYNv0WlVA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3817
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/mQyxoVPhXgTk3hvacuLo5a3WDOE>
Subject: Re: [Tsv-art] Last Call: <draft-ietf-6man-spring-srv6-oam-09.txt> (Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)) to Proposed Standard
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2021 09:09:05 -0000

Hi,

I have looked at the changes. I think they adress the issues I saw when
reviewing. 

Thanks

Magnus



On Fri, 2021-04-09 at 06:22 +0000, Zafar Ali (zali) wrote:
> Hi Magnus,
>  
> Many thanks for your comments and detailed review.
>  
> We just posted version 10 to address your comments.
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-10
>  
> Please see [ZA] in-line on how your comments are addressed.
>  
> Thanks
>  
> Regards … Zafar
>  
> From: Magnus Westerlund <magnus.westerlund@ericsson.com>
> Date: Tuesday, March 16, 2021 at 6:42 AM
> To: "last-call@ietf.org" <last-call@ietf.org>
> Cc: "draft-ietf-6man-spring-srv6-oam@ietf.org" <
> draft-ietf-6man-spring-srv6-oam@ietf.org>gt;, "ot@cisco.com" <ot@cisco.com>om>, "
> ipv6@ietf.org" <ipv6@ietf.org>rg>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>rg>,
> "tsv-art@ietf.org" <tsv-art@ietf.org>
> Subject: RE: Last Call: <draft-ietf-6man-spring-srv6-oam-09.txt> (Operations,
> Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6
> Data plane (SRv6)) to Proposed Standard
> Resent-From: <alias-bounces@ietf.org>
> Resent-To: <zali@cisco.com>om>, <cfilsfil@cisco.com>om>, <
> satoru.matsushima@g.softbank.co.jp>gt;, <daniel.voyer@bell.ca>ca>, <
> mach.chen@huawei.com>
> Resent-Date: Tue, 16 Mar 2021 03:42:05 -0700
>  
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>  
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org if you reply to or forward this review.
>  
>  
> A) Section 2.1:
>  
> I first missed that "SRH.Flags" is intended as reference to the flags field
> in the Segment Router Header. As this notation is prevalent through out the
> document, could you be more explicit about this notation and also maybe be
> clear on what a particular label represents.
>  
> [ZA] Updated text in the Section 2.1 to make it clear that the draft defines a
> flag in the Flags field of SRH [RFC8754].
>  
> B) Section 2.1.1:
>  
>   When N receives a packet whose IPv6 DA is S and S is a local SID, the
>    line S01 of the pseudo-code associated with the SID S, as defined in
>    section 4.3.1.1 of [RFC8754], is modified as follows for the O-flag
>    processing.
> S01.1. IF SRH.Flags.O-flag is set and local configuration permits
>              O-flag processing THEN
>                 a. Make a copy of the packet.
>                 b. Send the copied packet, along with a timestamp
>                 to the OAM process for telemetry data collection
>                 and export.      ;; Ref1
>  
> I would note that this  results in the following psudo code as it states
> that it modifies line S01.
> Did you intended an insert so that S01.1 would be between S01 and SO2?
>  
> [ZA] Yes, the S01.1 is inserted after between S01 and S02. Specific text
> stating the same is added to the Section 2.1.1.
>  
> This
> Psudeo code just lost its scoping to SRH. I would also note that it doesn't
> match the style of what is in RFC 8754. For example a {  } the steps a and b
> should be present. Also with the modification in place you also have a
> spurious } at the end.
>  
> [ZA] Added the RFC8754 style bracket { }. The added text has its own block of
> brackets { }. With the comment that the line S01.1 is inserted after between
> S01 and S02, the modified pseudo-code is now well contained in its own block,
> as follows: 
>  
> S01. When an SRH is processed {
> S01.1.   If O-flag is set and local configuration permits O-flag processing {
>             a. Make a copy of the packet.
>             b. Send the copied packet, along with a timestamp
>                to the OAM process for telemetry data collection
>               and export.      ;; Ref1
>          } /* Matches S01.1 */
> S02.     If Segments Left is equal to zero { … }
> …
> S26. }  /* Matches S01 */
>  
> S01.1. IF SRH.Flags.O-flag is set and local configuration permits
>              O-flag processing THEN
>                 a. Make a copy of the packet.
>                 b. Send the copied packet, along with a timestamp
>                 to the OAM process for telemetry data collection
>                 and export.      ;; Ref1
>    S02.   If Segments Left is equal to zero {
>    S03.     Proceed to process the next header in the packet,
>             whose type is identified by the Next Header field in
>             the routing header.
>    S04.   }
>    S05.   Else {
>    S06.     If local configuration requires TLV processing {
>    S07.       Perform TLV processing (see TLV Processing)
>    S08.     }
>    S09.     max_last_entry  =  ( Hdr Ext Len /  2 ) - 1
>    S10.     If  ((Last Entry > max_last_entry) or
>    S11.          (Segments Left is greater than (Last Entry+1)) {
>    S12.       Send an ICMP Parameter Problem, Code 0, message to
>               the Source Address, pointing to the Segments Left
>               field, and discard the packet.
>    S13.     }
>    S14.     Else {
>    S15.       Decrement Segments Left by 1.
>    S16.       Copy Segment List[Segments Left] from the SRH to the
>               destination address of the IPv6 header.
>    S17.       If the IPv6 Hop Limit is less than or equal to 1 {
>    S18.         Send an ICMP Time Exceeded -- Hop Limit Exceeded in
>                 Transit message to the Source Address and discard
>                 the packet.
>    S19.       }
>    S20.       Else {
>    S21.         Decrement the Hop Limit by 1
>    S22.         Resubmit the packet to the IPv6 module for transmission
>                 to the new destination.
>    S23.       }
>    S24.     }
>    S25.   }
>    S26. }
>  
> I would also note that if you wanted more generality you could replace a and
> b with
>  
> Execute the configured OAM process. E.g. if using IPFix that would be .
>  
> C) Section 2.1.1
>  
>    The processing node SHOULD rate-limit the number of packets punted to
>    the OAM process to avoid hitting any performance impact.
>  
> So this is protection against misconfiguration or an actual security breach
> isn't it. Because no entity outside of the domain should be able to set this
> on packets.
>  
> [ZA] Indeed this is the case. We have updated the security section of the
> draft addressing your comment.
>  
> So should this limit be configured by the management system or
> baked into the implementation.
>  
> [ZA] The rate limit should be configured by the management system. Text has
> been added to mandate the configurable rate limiting.
>  
> And in the later case, isn't the nodes
> capability to handle marked packets dependent on the total load across all
> packets processed at least in one processing pipe?
>  
> [ZA] An implementation may implement rate limit for O-flag independent of any
> other rate limits applied at the box for any other purposes. The packets are
> throttled before they reached the telemetry subsystem (or OAM process).
> Section 2.1.1 text is updated to indicate the rate limit also needed to
> protect the telemetry subsystem.
>  
> And to me it appears that
> the limit will be dependent on what OAM Process that has been configured to
> be executed. Thus, how can this be robustly implemented so that it doesn't
> interfere with the telemetry? Because if there are a mismatch between the O
> flag marking entity and the rate limiting, then the telemetry usefulness
> could be compromised. Can you clarify the thoughts here?
>  
> [ZA] As these are sampled packets anyway (like in the case of IPFIX), the
> controller is able to work with the subset of the packets reaching it (when
> the rate limit is effective).
>  
> D) Section 3.1 and 3.2: I have the impression that quite a lot hides behind
> the "The echo reply message is IP routed." or corresponding. First of all
> there need to exist a return route for the source of the PING or Trace
> route.
> Secondly, as this is routed without SRV the packet can take a
> different return route, and in case any firewall or other filtering is in
> place the reply may not make it. Is this correctly interpret here? If
> correctly understood I am uncertain if any changes are needed.
>  
> [ZA] The underlying assumption for ping/ tracing in IP network is that
> responder has IP reachability back to the initiator. The drafts is relying on
> the IPv6 ping and traceroute capability. Also, [RFC8754] defines the notion of
> an SR domain and use of SRH within the SR domain. [RFC8754] security section
> provides security mechanisms to secure the SR domain. The use of ping/
> traceroute defined in this document is restricted to an SR domain. The
> firewall or other filtering are typically performed outside the trusted SR
> domain.
>  
> Cheers
>  
> Magnus
>