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, 16 March 2021 10:42 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 5270E3A2177; Tue, 16 Mar 2021 03:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 l50U5cpJ7Ltl; Tue, 16 Mar 2021 03:42:03 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30072.outbound.protection.outlook.com [40.107.3.72]) (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 7999F3A212E; Tue, 16 Mar 2021 03:42:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nG6a7EmqKMttE/8m8Qlw/hZLxR4jrh+wwDyq4c7nqIrNm5Eqzb5ncMs77iOcq1tlQpklnjcapTeXjC+H1+h0mxzy7NgOG7SRHsXKYqONn2s88+kJ3LhannOG8b85LowqQwvPYc2AMWXOBFtO3RZ9j4fOZz+PCVqrGvk+oxonwTX8fmMrhvBVCXL8V/MJlI/TjRBoNjplMtlX0hnoKyfhWTAWsRBvajLW+1EJ9Hh9JIETZbDYu/E08Z+uPz3vTSNg3Q0WTkSwIt6m0PjM6fSl0aEDso2Z4OjmvQNSzt0dkSJ0uYWNgHHIyA8PY6a14pY7OsGSiiKCUlc4Q/PgelqYYQ==
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=qW1xOkpzndKvEtQ0ioLmqvtMhtSG6OZxhNdj8MfNtWc=; b=VqUt4XCvMS5m0fwue11rSYQ3XuA9G0q/O4IXXitpemOjL/TyAMOodXSzZUz1hXYcrC4CGej8KWG6qkqzmGqMSQ4EkglX5moCCR1npUZfpbQZw05SvoKRgCVfrJgPdQwBl11eCtAfXrCMFBZ+22esIjco6mrvIEeSP+D3J9oxj1D1J0zKnP9aQLkegC6YZlE6vuA7xCoy7eDuk3cPIEsPhH+JO7gRdFCvNk3vJ6FoiMVz/vdnDbDVptnIfE8zH2nSITfZtJ9Qdatkah9LBUXMXOD7qxtPQKDtXwjKdUsNS9DU2Cr3lAXlAzXPBJYdb/w9x/2fGNaEuwUpiNxr1aC/Lw==
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=qW1xOkpzndKvEtQ0ioLmqvtMhtSG6OZxhNdj8MfNtWc=; b=fnM4+xtBbmIcHl6R9zHavd9+TDHjXgY5iTJerMscnc5CK8X3UE7xzVTTkldTShhfgHxGbJwVws+gx+6gOke153TG4+VMetQZYQs57201HeKiH+07Vf5AQ2gnwYOGdk1uWp2xEkhCAuF8PwOzRCrnPO+JcCM3Jr41RamTKOdEVxI=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3452.eurprd07.prod.outlook.com (2603:10a6:7:2f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.10; Tue, 16 Mar 2021 10:41:53 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::350a:7431:a670:a5b5]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::350a:7431:a670:a5b5%5]) with mapi id 15.20.3955.010; Tue, 16 Mar 2021 10:41:53 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
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>, "ot@cisco.com" <ot@cisco.com>, "ipv6@ietf.org" <ipv6@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "tsv-art@ietf.org" <tsv-art@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: AQHXFA3fNj9hbVlrnUKMHhPDwH9SzaqGeQPQ
Date: Tue, 16 Mar 2021 10:41:52 +0000
Message-ID: <HE1PR0702MB377255546E2D196AF27DF22D956B9@HE1PR0702MB3772.eurprd07.prod.outlook.com>
References: <161520275637.3336.12802912189924676386@ietfa.amsl.com>
In-Reply-To: <161520275637.3336.12802912189924676386@ietfa.amsl.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
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.130.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a68a4e41-43d2-4397-8171-08d8e8681cdf
x-ms-traffictypediagnostic: HE1PR07MB3452:
x-microsoft-antispam-prvs: <HE1PR07MB345277A07801F8D573EC7006956B9@HE1PR07MB3452.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: x/EBUgw5/shgaK2xrDcsDkq0Umgcu6bF/+muf5vHRwdyWqmq9yPrSeOima77Q6iFooe823togMpO4242c5UYathiqzWEsWoYLnfyWAtkytcM/QMIej0i1ky89Uni7VO14GDq0O8N9cnVob9gyC+jZQwYeL421TvCX9fwZ9IenvxZZwSZDwZylv3QDjrzljuc4T+gCWO1EtxwaSvx6z6xh8sik3Qhlndyu6IijdIRRlCljxLGgSUyEk4o1/uBBPcP18+BhLM0rae/AlFdBuea0vKIaWyIbEXb963BCxPvOeGna+skGcRziggbnHlRX4/h0+Hh1A0jHNSIfd1hpBmy6BDEt9YH6gL7RryfbCclZiBWC9VkH+qVQUO4AjYdXxTuUIpgfVlhV4lDaLZt3VWYkIlFwilLZsX2vPgt178/tmEUIP4kbwYCaT4L1ckkDhnN3sK9wD8ecH4eZO6jJ7JI3P7xcFd4vVhUUUyl+xSXn1lCrIKp/OyqF/fJstZ4F1+zBtG35kNfM35pmvGXjOozHqDIkasyEpGcbLC2r6eh41ikujikPEaKrJLA29VcEwed
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)(136003)(366004)(39860400002)(376002)(396003)(346002)(66574015)(44832011)(9686003)(83380400001)(55016002)(86362001)(6916009)(66616009)(64756008)(99936003)(66446008)(66476007)(66556008)(66946007)(76116006)(26005)(186003)(71200400001)(4326008)(33656002)(2906002)(316002)(54906003)(6506007)(5660300002)(478600001)(7696005)(8676002)(52536014)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?SIUcNHkmjqv0GpfxyZqiulUBweCDq2+plm7guT0qa+JZtifko0pYmeUup030?= =?us-ascii?Q?OEbkRwq3/3rypIuU35hI4YR7dacXCrwedE9BxN5hCkbvL6kuEoXGkdxkUbMp?= =?us-ascii?Q?nifjrUiNY+moehI2rTIW92dlpV9Fl4aL43+eNMRnfbF78eT44+4AJYUUueO1?= =?us-ascii?Q?6M7y7BGfq49y8nW1Y5Y46875NUjAUFMUD1j82mQ1Nh9X8JSuYfT/SoF1br6S?= =?us-ascii?Q?onWunpTH7867aN8DDPINO6kHIMxFfSqZkzjfGbHLjGqT9lTzWAK2JsWiZkla?= =?us-ascii?Q?fmUggU74r3xqOck/yHhJA/0JsBf0uZ8fh5coRNBzMiQFuuC/zKOrJzZx/gKn?= =?us-ascii?Q?6F5wid6I+FMCQTblBRDthAemjsK3TN3P3ZqAk+BzvJquYBex8Aqam225kGB9?= =?us-ascii?Q?QWbDlENkAC6KpSY0zNYm5ooKzkK6j2/t/HvcOiVsqHto1RRKk86tEqKfeXru?= =?us-ascii?Q?hK08eq+Ae8pjMZvJbB3yesSS7HM6FN333+VllVV7jSZO17NwmhEmJugsZss/?= =?us-ascii?Q?tNKHuGWl+Vjs4TTXkAVPuVRNnFk3tFEaQ9/eSqpYRrNUVdqf+n+LEEK5VcFd?= =?us-ascii?Q?8JH3T5alDG2a2nZoCL/MzqYUiQi1sosp8bXIXd+pDSKFUEI1UVlGsUBpLIyW?= =?us-ascii?Q?fGq4bwDXi3FLfgyG8pwyRSSEKAtfLXoo7QwsuJ+Eq7WiI4M/zM/HyB+nR6qV?= =?us-ascii?Q?vtrMG2+YKBE12uzc3vjORnwMriybSge0rmMXPK6M3YDlrCUL+9fZ0LZQ6b1b?= =?us-ascii?Q?fsrY9IzoQ219qXN+l822hJOC8ObyNU0/zc1HzJU5/S1h+H2BlhWRAEeIaNwM?= =?us-ascii?Q?/o/rY+dwWgdVN+YMuDVcxUx1FUHtzIe+ZHzrZAiDh/+1Ih93h5ISuUGJI+qT?= =?us-ascii?Q?169eAY7H2FrPjmRWLC1gFycMe2rAZXpyy5z9Xuc8M97m27qs2CW7s5+e3880?= =?us-ascii?Q?vusLQMQfU3Za/yZhroi7wHbEQXJDLHwhS6hHJoOWj4wPdyyuEJQtQG3Wi5pd?= =?us-ascii?Q?RsgfGZib16EDf0NoGGRlukTbzyXy+KxnLvsr7HfNi0QjsLIw6UNm7AIzU7R1?= =?us-ascii?Q?Q8q4RF9mTSfFqcIfMnIhR39WqBDcOBTuWhhiN80oKeESgkFgWPfT3ZxRSsRz?= =?us-ascii?Q?gpxkvNWuetVc9a0keha8J2bflePIMN9HXwyVvHcpTskGoYAjThKZQkOSCimj?= =?us-ascii?Q?xvvPEDl27ePKZuKOnqI3DJPh/18R8o2dqXdxz9g983kOCa5JkjPJxTIsxb/+?= =?us-ascii?Q?SCNLTRtFvs0TYh8yTuhE8qdaOrfYsGCPIcHOVeSmg0DO7qYzx82ZQe27gbfM?= =?us-ascii?Q?36zjtwb18+nChceWdtKphVzv?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005E_01D71A59.5B1A70F0"
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: a68a4e41-43d2-4397-8171-08d8e8681cdf
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2021 10:41:53.0458 (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: jbtZ/R6L4tonDkPFe0E2/7BmjwYHauw1WtT3Jg1tYubbRgdaMXRJ1gMr0A2uD/n3tZ3F/rTLPxIWJD4ZB1Qn+V06SVqglp6KJ9V0D903BCM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3452
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/1gB64gcq-DFBHt96BSh0_1CwAAE>
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, 16 Mar 2021 10:42:06 -0000

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. 


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? 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. 

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. So should this limit be configured by the management system or
baked into the implementation. 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? 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?

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. 

Cheers

Magnus