From nobody Wed Dec 2 02:37:09 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EE73A12C7; Wed, 2 Dec 2020 02:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-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=btconnect.onmicrosoft.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 9DACKkQG0Cmn; Wed, 2 Dec 2020 02:37:04 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70114.outbound.protection.outlook.com [40.107.7.114]) (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 A1ADA3A12C5; Wed, 2 Dec 2020 02:37:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WWWGJ6rI8itj59z4MA3F6GNiThxjNMt8WQkzEIoB1L9amzXHwZ9QzGa1vPoSofK893Y1n8zW/u5FX8eb5jYzozl+UeE+V8pfOT9zXfhWzVDytHwXe/rvLOe1hb08UkriGES3Lz/E+O2QnNJf/9qC2dW6YV/ty6iJ7uoVvRq0do6tyEGwSwggvmAhnkOOlOG4rXrtRH5OFz73F053mqMtrOey722vXJdII2bk4FbiLE98/2IeRQ/epaQbY5ZbH/ZC9HC3uCBDfM1SyUZYZq6Td5kPs587WqlMC+bDAbIRloHlUezbRQuVEbLaV+r+0HKKRzN6b7HbAgShOsfuVKNoJw== 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=q0s6nKwYS2S/iyIkvbzkXvXVel1WrwRuY2s9J7Iopwo=; b=msquzfNzWIXv1jY5w/7PGZwDTeqKzG+Am+1K/cTy351og5LVteR7GTKD54RL2bYluxh/DI4bZPqfOLfIYgIfmH+2QlBmfr03WSBL2YVuZTEqdQPphWNz+nUVuty3F9CbTwNIWESH5oKOqXHTJX62TSy3/j5G7y8ygoczTRKB5SneIV1XbPTKoeK0ExGV6k66YejJoi4n2x9/+zUmRSNQ25YOVkMGZs3k1XpWJM7s1JhIxgn6/f2Z/3neWj8csKFjZnckmE0FaB/v+1Rpw0x6igAV8LHqTubp6qYifS0hr/sBBe6QkZFpSyLNU7rRkgNRo4Qtwczc+0FOXmWArw8I9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q0s6nKwYS2S/iyIkvbzkXvXVel1WrwRuY2s9J7Iopwo=; b=YD2Ry4LLioX8uG3usiWAxXWhFCmjFGdzfCYnpkn0nL4XYKpKh3wgQVvvbFXBekflYWD1Jbctr6Gj58bfKczjCnFt5alcbNgrLGWwQNhSw5o67XMOypMdqR0Vcip+X64BgBoI9u20ObWbWUn/731ioNANTYaNnzrp8aK9CtMoQGE= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB3966.eurprd07.prod.outlook.com (2603:10a6:803:37::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.16; Wed, 2 Dec 2020 10:37:01 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3632.016; Wed, 2 Dec 2020 10:37:00 +0000 To: last-call@ietf.org References: <160624221011.1004.4337499034959566457@ietfa.amsl.com> Cc: acm@research.att.com, ippm-chairs@ietf.org, draft-ietf-ippm-ioam-data@ietf.org, ippm@ietf.org From: tom petch Message-ID: <5FC76E4A.1000804@btconnect.com> Date: Wed, 2 Dec 2020 10:36:58 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <160624221011.1004.4337499034959566457@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [86.146.121.140] X-ClientProxiedBy: LO3P123CA0014.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ba::19) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.140) by LO3P123CA0014.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ba::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3632.17 via Frontend Transport; Wed, 2 Dec 2020 10:37:00 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d1bff299-091e-476c-b0cb-08d896ae33ba X-MS-TrafficTypeDiagnostic: VI1PR07MB3966: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: yt40sP6HswtmStPBPJouX8OoG2dO6nr9AsCzGrCCiWUKamXr9DhTeFtDmYkgVlaA8GM2aA56VWzz/tyLpT1xyg25u3thjlqiqx87ky2dAzZKXrwIoMJtGFubo3sfYR9mp6NQpcecEjgBESUq16RCODTj5XSUILMSCHPwFFtm6NFUNK88S9UQuoBIyrjZKZKvvvz/Q27dbPFTVIEh4KWkcEWdfbORKsjk455PtbbIjjqfuJPjOyJGUXQZqllptNLcfa1hIMZs+z8VZbVyHBgcskiQF9+HEX3D+1R0Ip8FDIGxpGsywyPgrk/fgTV+tV00VndMbx5dNc3PRmd+zMOqgJbNFnojfv96JKytGqrVtTcTcqOE8nmGvnZoTBYQ3869Fx/t0XB1ihWVQc+xlCWUkA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(366004)(39860400002)(396003)(136003)(966005)(5660300002)(2906002)(2616005)(66476007)(956004)(66556008)(66946007)(4326008)(6916009)(53546011)(186003)(16526019)(26005)(478600001)(83380400001)(8676002)(316002)(6486002)(16576012)(52116002)(36756003)(87266011)(33656002)(8936002)(86362001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?Windows-1252?Q?F5po4TyeOANZv6daEkgf0aJ849nMA3FSiJsMNmAM6zzqsRwwWIDWRRA6?= =?Windows-1252?Q?YnKK2yeQblH9TpvZQtbH18xWDXmw3t5nXbRp4cqOINCb7CPl/pOsamLf?= =?Windows-1252?Q?MoDyJR1roKAVTI2Nl3Hzo4Iqa5nJPBidiOxYoXEEAbEX+RbeEy9IlZpy?= =?Windows-1252?Q?hnkGqZ3dVmHuCD0kdHW4BeuvoRKj1n3mIm5ccmOQR9qKksGJ+/OSR8b1?= =?Windows-1252?Q?94hGBRM3MEx6STpF1w8SprrHs6GyvIasYe/hEBp4NFEqss+nCDDYOdYp?= =?Windows-1252?Q?TN8YeGu4bsgB1cV8SoKCyPFL1twW1HaBYPJLbAyDeU6KfQWxj95WOj/k?= =?Windows-1252?Q?HTmZE92bn3OaQSb/15mazgfFsrK+fRY3TEYW5rlWGnZToqroGVZbBC/F?= =?Windows-1252?Q?DATFuIG7fwIl6xTBa74qC48IvXHL/82yAWUBFXn9TL0r0mQehZ80s9Ln?= =?Windows-1252?Q?VvLZL9JZ3QchmhVXcBvWgsJqQvUHmyORP60Lyr4LyACaY6YGS6UVYs8U?= =?Windows-1252?Q?BGYGYY6PM7WiL8A2rg+hyO08IFZppirqLRE3hRVM8pd7Wjkc0x95ukrY?= =?Windows-1252?Q?jrhwVDbgVjTtpyf/PQRTIXSlrM4bX0ET4VlKQdSBwJcx5XHbpMTA+SgL?= =?Windows-1252?Q?KoEo2fFOsm1bhniDSZMSxjz4Rk+JCe+5STp0MVF85rSovPAw9qQw3lRX?= =?Windows-1252?Q?UdiDhLS+mr04caBdaCLkma9b0oX7wWJAdBKCyFWb5cbSpAIoBI0gjy92?= =?Windows-1252?Q?I8COXSY88sPxLGjJZksSFt1fSFmtPL0QGFcs8MZXHbRmCeJWh8+5VBmY?= =?Windows-1252?Q?1b2w5B8Dcmei4BcthPO+6YFDe7XXjIOXxgibQQKnCpADnom/cJVNwHzK?= =?Windows-1252?Q?ZeEakQ+Pp5PIJqE27RYgPpeZWZTOcgDlgHAFB9I1s2Ipx7nFrZHk26Yn?= =?Windows-1252?Q?WL4lj4PZuuxzTvfK0EWwgtmLn/N6LTQXNdGiBYlE0KBa4+koxvtMwOTP?= =?Windows-1252?Q?T0k+pXNv5VjG9fJigzNRQsZnTSIWygdNJCjpeK29I5buPyTMLHDVcXb1?= =?Windows-1252?Q?i7/pnHjrUWuQtmqJ?= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2020 10:37:00.8178 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-Network-Message-Id: d1bff299-091e-476c-b0cb-08d896ae33ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: WhIJnIAobecfyspfNs33AWREjcacLQRfdRgeg4KRgYWDvNjFVw0sA99t12Oksn2ReWZjYCxKbK6h/5UesZ8cLQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3966 Archived-At: Subject: Re: [ippm] Last Call: (Data Fields for In-situ OAM) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 10:37:07 -0000 This I-D seems at odds with RFC8126 over the use of Expert Review in s.8.7 ' The responsible AD will appoinht ...' RFC8126 seems clear that the IESG appoints and may do so in advance and having more than one is recommended 'the expert will approve or deny..' RFC8126 seems clear that that is the role of IANA. The expert recommends and it is then up to IANA to act 'the expert can approve allocations. No, that is the role of IANA; early allocation is possible but that is the decision of IANA. On 24/11/2020 18:23, The IESG wrote: > > The IESG has received a request from the IP Performance Measurement WG (ippm) > to consider the following document: - 'Data Fields for In-situ OAM' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2020-12-08. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > In-situ Operations, Administration, and Maintenance (IOAM) records > operational and telemetry information in the packet while the packet > traverses a path between two points in the network. This document > discusses the data fields and associated data types for in-situ OAM. > In-situ OAM data fields can be encapsulated into a variety of > protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension > header), or IPv4. In-situ OAM can be used to complement OAM > mechanisms based on e.g. ICMP or other types of probe packets. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/ > > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/3526/ > > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > . > From nobody Wed Dec 2 02:46:33 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898093A12D0; Wed, 2 Dec 2020 02:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-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=btconnect.onmicrosoft.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 RMZqzVl3jFx4; Wed, 2 Dec 2020 02:46:29 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130128.outbound.protection.outlook.com [40.107.13.128]) (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 3BF903A12CD; Wed, 2 Dec 2020 02:46:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lEO6W0fp8C6HqZl30f3waQvNym9ZC4E/f66GyaqMjJDhmROES2PJddiJxx5jwFiokmnA/RUVJ7na7wBCp6JA6GelmrnEmNEd8whuHI7qk18dtrudCWy3hIz1FW6owR45BfyMuadPsS6LO3MAcT1zS6edNS/ewP1znXPBUofnK88Wjp50oNCL56qya4a84dBr6lzg6UOLGoz9LIvNKKkUvQGVsB2xUdJo9wapD24mmj9KcTIVKsrCeFAI7Y9NTtF2E9okGaUVwF2r159LYsrB/5i+zc+An4PIDG5BoEduLk2aRr/4eOkQ8swEbKIU3SRqsjVRWExDmkgqeVYJOfJ2jQ== 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=zdLMQ5z7gFMWlN+gSEyLrJFx4Qw14k9BXplp4Rds7hM=; b=LSWqkUnkEXVZUB5oeTduij092dZ61ejXAxVGiuFcPdl7Q/mjuYut7udnZir1gtwCOlF6EFFylTBZrCSv6DRk8MMifgv2lCExCbsidlOEIEjpEyDfB/re7cNTX8XYhqzFlphY3ce+JJzwDUPs8kxhINFwvyFflmh9pY1f+R/QUWcroJTPfN3YLwNXi8ZjyP8Eeb1cSbq9ah00Dpis4+0FBmGua+rtzCxfkqPyLnhHWmXlJVR2Uhvl3yIVbgon4zKUvTvJ/Yhrt42P96g5RGFSuOt9qFqCmo5alWW5S89TMopX4XBHv8pXfnLcEj7wI42YXjOyNZDOgwFDMtWclcojvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zdLMQ5z7gFMWlN+gSEyLrJFx4Qw14k9BXplp4Rds7hM=; b=Xa0dCx+mKOdT1i1YyRpczsGuFm/QV2x+HutMi3oyBr3I+IRf5QdAJYvwzRN8JkUvQ+386Pza3NKn/+1tG74jArl1e7+oKlBfpmvC3zOLDHuTgY6kRMldDGGRWkL5iqiI0yEBNnkY6pTG80BqEiZlUREyUvOCKXIEPkMHIbqWtFU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR0701MB2576.eurprd07.prod.outlook.com (2603:10a6:801:12::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.6; Wed, 2 Dec 2020 10:46:26 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3632.016; Wed, 2 Dec 2020 10:46:26 +0000 To: last-call@ietf.org References: <160624221011.1004.4337499034959566457@ietfa.amsl.com> Cc: acm@research.att.com, ippm-chairs@ietf.org, draft-ietf-ippm-ioam-data@ietf.org, ippm@ietf.org From: tom petch Message-ID: <5FC77080.7000207@btconnect.com> Date: Wed, 2 Dec 2020 10:46:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <160624221011.1004.4337499034959566457@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [86.146.121.140] X-ClientProxiedBy: LO4P123CA0029.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::16) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.140) by LO4P123CA0029.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3632.17 via Frontend Transport; Wed, 2 Dec 2020 10:46:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4bfea883-c3a4-4f09-ee67-08d896af84ca X-MS-TrafficTypeDiagnostic: VI1PR0701MB2576: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4941; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: em5jNyVC3R9yKrsTJ2HmPMZ09QWsgZsVBype2gDKUek/lcWA+rbMHsBrRuKrK190JFz9D98mPpRwKB8gCNFFhUQNVJDxUNtValKnqnkAmAFur4x8XXJ7sjByDoWfgNqXiH4WbH9AC5/Mgb4q+3zAgM2Btt+/tgXB5T0nJvHDh3E06vGWdWCC+i+imgDN24oEiPMpaJ6fmhrMmiFHScvIzcGOiRBLeIATzFuWVmvrumWF/kAoSBaeoGWJ2t51LlePEDKR3C63zRVflUtz6Mwh16Vvfihi077UmVNGsFFt+pPUYi0N4nMLCBxm4GV/mqD+/QgbQZnV8Pb26zRVwz+soQLLu9dTgplQxSUB6s25GHSG6bhoWQVaBgXuyQb2kATkZ5QCKD0YiHr9a3JciChucA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(376002)(396003)(39860400002)(366004)(2906002)(4326008)(966005)(186003)(16526019)(66476007)(66946007)(66556008)(6916009)(36756003)(83380400001)(86362001)(26005)(478600001)(53546011)(8936002)(956004)(5660300002)(33656002)(2616005)(6486002)(16576012)(52116002)(87266011)(316002)(8676002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?Windows-1252?Q?SHVYXF7QjwvHb724uKTsAr/Rtyy74w+HI7iMUcURlfHDqce52N5ef9WU?= =?Windows-1252?Q?QsZw0sV+wFRBwqjzaHU93mnJ/HrlruJlaeJdD5qMhT/L1mHA4oJB0JHz?= =?Windows-1252?Q?UYhWyfFHexBAs5mjWuJhDxw8r42utaekPOZ/V6sNWrc3MD8M2719XW/o?= =?Windows-1252?Q?5DeiKOr3rPJsrPkMauAgnQmX59Dy98irPfPEHw2YpS7Yu8GBJCOZb8Fe?= =?Windows-1252?Q?3d0qmoUCoA3/eIEbTXvds6YtJyvDl1hd85N7y0k0R8vdBXs3K6cTaBZ0?= =?Windows-1252?Q?65EAGv6wEFEIQyPIvLAMOW1HB0FQpcjXdIqWK0lFXO/0+8mi2NFmQfPm?= =?Windows-1252?Q?xV8pUR16CKSirAtekzf16UNjTJhhWhr8kRQlqm/QuG4GORf7EtTiqDRV?= =?Windows-1252?Q?wmDddA5tQiMi8cgvEwb3lzcGDdhfDSWNUUK8usTAL643KBdxyeI9c2az?= =?Windows-1252?Q?hzBK7TgHhpQ5445X6QyMBhw9xQekDAPfr4LeBnyKy0vMCSq2Nzr7adH7?= =?Windows-1252?Q?A4Qjgl/ay6tNCP7hy4Vf56Ul4RTzXgHiBbBOnoG87xGbETrjH9EL95WN?= =?Windows-1252?Q?onQq0wArIDRBWAusWZPYkoGe+hxghqkSzlUJN2jIaDNfDQ8ZUWkOKptv?= =?Windows-1252?Q?oHDPq1SwCTTxdpixZx39OjT5cDrkYh+GJd0p4d2BS83szgO2lsnmJCJ6?= =?Windows-1252?Q?UToiEMmxiczu2vsQlB60XFEUZ2oyObytCI8qV7WU4Sa6MxJV5SwASNej?= =?Windows-1252?Q?Ep+Zsv33JFPbU2LKyhI8OGwh5HiZbQWwAfqoWP+WcgXju9SRZMygda85?= =?Windows-1252?Q?G5B76VJJzwZondGg39PQDS4mhDJyvQnN3iXNKTcTu7ELTfD3OD6NhWuC?= =?Windows-1252?Q?SWvfKeJ0olkvFQrEcqkojCCHYx0g+oNWAQi49j2bZ8nVyC4csHb3ri3u?= =?Windows-1252?Q?Rp4sK8sqWwwRFoEpiDISta0ITMO5uuHaVhh93TGHHro5SA8S8Qll5lwI?= =?Windows-1252?Q?FNmJy+A7V0bXHe8bZ43mqvRxG2zjwvIJT1l59E7s/qOEqz28b3tN2n+j?= =?Windows-1252?Q?MSRpoRN49r08ZgJA?= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2020 10:46:26.3075 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-Network-Message-Id: 4bfea883-c3a4-4f09-ee67-08d896af84ca X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: FScR2RQexKM/b11IZW1PhD4/S+n5WxHxhhBYqq0OT5WICdXlQ8OoO9o9ft/j3mO0H7/BiTqssizjbdk0VUGOzg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2576 Archived-At: Subject: Re: [ippm] Last Call: (Data Fields for In-situ OAM) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 10:46:32 -0000 This I-D seems at odds with RFC8126 over the use of Expert Review in s.8.7 ' the responsible AD will appoint ...' RFC8126 seems clear that the IESG appoints and may do so in advance and having more than one expert is recommended 'the expert will approve or deny..' RFC8126 seems clear that that is the role of IANA. The expert recommends and it is then up to IANA to accept or reject. 'the expert can approve allocations.' No, that is the role of IANA; early allocation is possible but that is the decision of IANA. In passing, 'The meaning of bit 0 perhaps better as value 0 s.8.1 /this draft/this memo/ s.3 needs updating to conform to RFC8174 Tom Petch On 24/11/2020 18:23, The IESG wrote: > > The IESG has received a request from the IP Performance Measurement WG (ippm) > to consider the following document: - 'Data Fields for In-situ OAM' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2020-12-08. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > In-situ Operations, Administration, and Maintenance (IOAM) records > operational and telemetry information in the packet while the packet > traverses a path between two points in the network. This document > discusses the data fields and associated data types for in-situ OAM. > In-situ OAM data fields can be encapsulated into a variety of > protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension > header), or IPv4. In-situ OAM can be used to complement OAM > mechanisms based on e.g. ICMP or other types of probe packets. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/ > > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/3526/ > > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > . > From nobody Wed Dec 2 04:50:52 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61723A1392; Wed, 2 Dec 2020 04:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 X9c1olHtL65C; Wed, 2 Dec 2020 04:50:48 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40092.outbound.protection.outlook.com [40.107.4.92]) (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 5BA4D3A1393; Wed, 2 Dec 2020 04:50:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L3S8oyHLTVL9cLW9XZ8o0eKFLw2aBjJE8kqqI9354xkmOEfyga78/BfmRsJdMQ5+MTtxV5kyiEV5pE9JMo35br7+JXSIEDwHPJ++pGgxB1K6alVUNDweVQ0DZwXYqWWhw/gGAR9/H+BCLc7sw1pSxktSEAo7ldhFKiXZ1SXtUtEMAarntCiRCjTebJE1NNHtOEd/CAJdgr/Zf4Fy0nCNfa55lYUkizsdHPhADZzgiFfxoBxRPQ14nIBSHmt+jFgYwwMv/JvE50iYvqABiWC9B1mVBgpxErPBCrEttCiYCj4SN2aAdGgSaK2AjSNp/aLtLd/Bcsikno4d3PXykBc/7w== 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=+0TqygNBQz+72Xs54kxAWp51fziHGeA7tQ3EqrMQkFA=; b=Oz7DYj1s4DCvy0bJ/XLUnnaNIAWPrbWF5EsO/oE7a1Rt+Kdb3K5KUumGjk1+UQibVZAznDiGPomxfkySvJaWfAjNzzexAl0saYtlm6dcHTO8EBQX+YOk0ucFm0X9A7U9pYjKkDR49RePmS59wSTS4EsRNhYjNyelAXxVPH2Nq3WhhmAwNG/wi76drBMwyyk/C+4nRZSlX4Hab6BI8fwOJhYJak+TTXSN97lJ1bmPy69nw2Lbk1oyNF5ErYETMPYEfr37CmB6BklFPKM1BUmwcYe2pWxFtK7sak3zRHuhSFw0AFzHtr6c/pL5ChBtimuUzmRReL4wvWAUB3NJMhahng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+0TqygNBQz+72Xs54kxAWp51fziHGeA7tQ3EqrMQkFA=; b=Cp9I1T/7CqdfxfPoxTB4EKl997a93FKfB8LituKaq0HSlqvbUBmHyf3laDv8++XHB+656ZCLIPP4M6QfydFqYDqu/+5LURCpD5hzL6Y904rFjDeoCp9hCuGKFCM25lkF4UQLo0LKXUlOdTiZoJtA/oFfcHUIwYGD2SvbSmZgCFI= Received: from AM6PR07MB5784.eurprd07.prod.outlook.com (2603:10a6:20b:95::29) by AM7PR07MB6563.eurprd07.prod.outlook.com (2603:10a6:20b:1ac::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.5; Wed, 2 Dec 2020 12:50:46 +0000 Received: from AM6PR07MB5784.eurprd07.prod.outlook.com ([fe80::15d0:d260:35ea:7c9b]) by AM6PR07MB5784.eurprd07.prod.outlook.com ([fe80::15d0:d260:35ea:7c9b%6]) with mapi id 15.20.3632.016; Wed, 2 Dec 2020 12:50:46 +0000 From: tom petch CC: "acm@research.att.com" , "ippm-chairs@ietf.org" , "draft-ietf-ippm-ioam-data@ietf.org" , "ippm@ietf.org" Thread-Topic: [ippm] Last Call: (Data Fields for In-situ OAM) to Proposed Standard Thread-Index: AQHWwo8oCsvh6gBv+EKSISTQLUxKfanjq6MAgAAiF/A= Date: Wed, 2 Dec 2020 12:50:46 +0000 Message-ID: References: <160624221011.1004.4337499034959566457@ietfa.amsl.com>, <5FC77080.7000207@btconnect.com> In-Reply-To: <5FC77080.7000207@btconnect.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: research.att.com; dkim=none (message not signed) header.d=none;research.att.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c333af17-4fcf-477d-6304-08d896c0e339 x-ms-traffictypediagnostic: AM7PR07MB6563: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7Z2yNs/iDtAFvFeehAMC0KuGj630dVMj36gk84pR//ft8d+W0S84FHe5jUa6zWrA8qRpmsaxtQeduU+d8dDjqBno8Nbkq35xi5Bfr9oKZ3VT2+kN62EAMalVRtxdsj+53yhED6dZ1oeGwr3k+8SzoWw6H6V7NaS/c6SlSyUr4LLiuh+wIPA1QBx8rSLiGfSoDqs9xJn/u/u7sYAhAcrwe+rIoozRCVyfK3oO3WHZeufJYKuVolu8MiC9YqttprUvAlAIlNEjm2zmLsRLdoeVndl5C4p9F2Cs1Yb1Is1DbdNEYaw3NVQ7Dj7cV6+hwJZTm0meoQ9zob/ofwbatcWQyyb3VUvQCezIzl+f8PlxzUXJU4MFn7GP8PTmTh4BMEaNis/lREeSRM3JhNZTqlBNlA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB5784.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(366004)(346002)(376002)(396003)(6506007)(7696005)(966005)(478600001)(4326008)(8676002)(8936002)(109986005)(83380400001)(54906003)(66446008)(64756008)(316002)(5660300002)(52536014)(66556008)(66476007)(66946007)(91956017)(76116006)(53546011)(186003)(26005)(9686003)(55016002)(86362001)(2906002)(71200400001)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?79wTFR9xvv6IKu6aMDpQKrRQo8LypuLDzCuMuvQK3/G80v7xXHg33qnJKS?= =?iso-8859-1?Q?zREL+s/YcN783SvV2/JHCYfHNXxZxlwreLZe+eESN4FjRxDYK7/AU8jNef?= =?iso-8859-1?Q?p+dn7dMQDrpCcHYCT+dU9PEzoRw9hKZxNfeaAcX/6OxoservKHj0XxWTQ/?= =?iso-8859-1?Q?ZuIxEm7a2O3/DU9O+NrpGLTuC+HegtjwL39XLtOtoKiTm4gQdFDHR7AzSU?= =?iso-8859-1?Q?0M3GZFhBV4C4cBrMcULYwHZU3pJHWvdICCbI/2e/5SvEyeTzB5BRJAGOqr?= =?iso-8859-1?Q?OmSgxGd/nqLG94rxcxAcOBBYu2jC+vAGBnCTerZX/v9jE1blaGct8sdo1J?= =?iso-8859-1?Q?9LF1/EXFBM59pM1fO6i4p28g/WVKjAt5+R44Bs8P36E40cuKlmM7RtVYpe?= =?iso-8859-1?Q?nD+dopL8yKKeiOZaDUyXxZCCK6p8GM2GfvakE0gPWYgDvOVNSbiHyZAYE2?= =?iso-8859-1?Q?gZpDDrWjJJLhvd7GNzxiyfZWnbA8KNA6xn0XvsWnGL91xAMVFSkyqywWDA?= =?iso-8859-1?Q?yixI8sjOgXg2y2UDbGbZKL/qSoE0mhGNBiwMKWLYBseRq3rT6K5DHZ6CGo?= =?iso-8859-1?Q?h6PVxOCE9wnIxdu8g8hAARFXmL0Ia6yEEyklBHbXFYNh3xa6QmiMLLCOFW?= =?iso-8859-1?Q?Z8lsJYJHcD/FaTHFSMimiBcyMa3FT9o3GSD7M7gc4Hr9/LSgR1LyhMVaJZ?= =?iso-8859-1?Q?AHd0Hbq75N8SDLdw/nCHraMGyztvTI3UHyNotXEFV//waPR5aeDMLPeURu?= =?iso-8859-1?Q?xgAqcucoeQmNR/TnBxeKHNi2ygc4pJeU2aH0A2jnD/G118Z+PEbaD8pptg?= =?iso-8859-1?Q?cV0p47eABR3L/Tczup0svhctVcw13zgprMeqgQblKKj9/T41BACZUfLxlR?= =?iso-8859-1?Q?frTkDCO1kepLkLoBmPgAhzyigt2Hxtg8rZqOqABTDa40ly8mhrK4sHcVvX?= =?iso-8859-1?Q?0MEC15pghKOLYkntx3ysQj9sVahpCnjRDzrzOO1GAChtnFPo7qbXYkqg3r?= =?iso-8859-1?Q?5XrRyyCpoqgycxcoc=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR07MB5784.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c333af17-4fcf-477d-6304-08d896c0e339 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2020 12:50:46.2141 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oms/MHWHV4vs+gPEFThHgaJRAirlG7vyLdCqCxZfU17imf7eDQXH8oqg2wlcZoUyvYdGR33EEqNz1kkrJfad4A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6563 Archived-At: Subject: Re: [ippm] Last Call: (Data Fields for In-situ OAM) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 12:50:51 -0000 Sorry about the defective post before the one I meant to sent.=0A= =0A= Both get bounce messages that delivery has failed to=0A= shwethab@exch.cisco.com=0A= which I note is not the address in the I-D.=0A= =0A= Tom Petch=0A= =0A= =0A= ________________________________________=0A= From: ippm on behalf of tom petch =0A= Sent: 02 December 2020 10:46=0A= To: last-call@ietf.org=0A= Cc: acm@research.att.com; ippm-chairs@ietf.org; draft-ietf-ippm-ioam-data@i= etf.org; ippm@ietf.org=0A= Subject: Re: [ippm] Last Call: (Data Fie= lds for In-situ OAM) to Proposed Standard=0A= =0A= This I-D seems at odds with RFC8126 over the use of Expert Review in s.8.7= =0A= =0A= ' the responsible AD will appoint ...'=0A= RFC8126 seems clear that the IESG appoints and may do so in advance and=0A= having more than one expert is recommended=0A= =0A= 'the expert will approve or deny..'=0A= RFC8126 seems clear that that is the role of IANA. The expert=0A= recommends and it is then up to IANA to accept or reject.=0A= =0A= 'the expert can approve allocations.'=0A= No, that is the role of IANA; early allocation is possible but that is=0A= the decision of IANA.=0A= =0A= In passing,=0A= 'The meaning of bit 0=0A= perhaps better as value 0=0A= =0A= s.8.1=0A= /this draft/this memo/=0A= =0A= s.3=0A= needs updating to conform to RFC8174=0A= =0A= Tom Petch=0A= =0A= =0A= On 24/11/2020 18:23, The IESG wrote:=0A= >=0A= > The IESG has received a request from the IP Performance Measurement WG (i= ppm)=0A= > to consider the following document: - 'Data Fields for In-situ OAM'=0A= > as Proposed Standard=0A= >=0A= > The IESG plans to make a decision in the next few weeks, and solicits fin= al=0A= > comments on this action. Please send substantive comments to the=0A= > last-call@ietf.org mailing lists by 2020-12-08. Exceptionally, comments m= ay=0A= > be sent to iesg@ietf.org instead. In either case, please retain the begin= ning=0A= > of the Subject line to allow automated sorting.=0A= >=0A= > Abstract=0A= >=0A= >=0A= > In-situ Operations, Administration, and Maintenance (IOAM) records=0A= > operational and telemetry information in the packet while the packet= =0A= > traverses a path between two points in the network. This document=0A= > discusses the data fields and associated data types for in-situ OAM.= =0A= > In-situ OAM data fields can be encapsulated into a variety of=0A= > protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension= =0A= > header), or IPv4. In-situ OAM can be used to complement OAM=0A= > mechanisms based on e.g. ICMP or other types of probe packets.=0A= >=0A= >=0A= >=0A= >=0A= > The file can be obtained via=0A= > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/=0A= >=0A= >=0A= > The following IPR Declarations may be related to this I-D:=0A= >=0A= > https://datatracker.ietf.org/ipr/3526/=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= > _______________________________________________=0A= > IETF-Announce mailing list=0A= > IETF-Announce@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/ietf-announce=0A= > .=0A= >=0A= =0A= _______________________________________________=0A= ippm mailing list=0A= ippm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/ippm=0A= From nobody Wed Dec 2 07:32:16 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF7C3A145C; Wed, 2 Dec 2020 07:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 sF7yD9kQq-28; Wed, 2 Dec 2020 07:32:08 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 295DE3A133A; Wed, 2 Dec 2020 07:32:06 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0B2FF1w7005706; Wed, 2 Dec 2020 15:32:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=VFZQQVYFWbJdxT32UWrBNqG2NeiCP25gjX7whAAgpYA=; b=M246BtUCKKUV32eECmnNfyOji9NP020Ilb8iEQAN7eBNdCnpaneODLJe9LL8EAgfswc+ 5QC/EdG9523rarY9Bnl6ZVlDOMDtTfX60e0Go7L+Bz7uHl4RJ1h+RkAuqyUcY+y3GRy8 VoXfG7Oj2vUVUrXhQr1HcBcTAZ8N3cPJqf71w7qAIr4ZJBqJe8VgU879ufP5niUZWfFc ffUJ4VY4rwtxSVA4BPiNE36U7wdoymWfPRIkqBm7MiAQnfphZZxpbugTaHkuc6B6mbS/ 1wpBQ/ZzJGPDaFcJAqJcOcRvn/SrpA9/4aXHxQZhjy/fjqaFihBfVnJCutdoHIS0MRzF CA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 355v3rte3w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 Dec 2020 15:32:02 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0B2FJ2g2022016; Wed, 2 Dec 2020 10:32:00 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 353js30j9v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 02 Dec 2020 10:32:00 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Dec 2020 10:32:00 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.008; Wed, 2 Dec 2020 10:32:00 -0500 From: "Salz, Rich" To: tom petch , "last-call@ietf.org" CC: "acm@research.att.com" , "ippm-chairs@ietf.org" , "draft-ietf-ippm-ioam-data@ietf.org" , "ippm@ietf.org" Thread-Topic: [Last-Call] Last Call: (Data Fields for In-situ OAM) to Proposed Standard Thread-Index: AQHWwo8QJsQwQie6ikSnFK4edTSvbqnj/NIA///+nIA= Date: Wed, 2 Dec 2020 15:32:00 +0000 Message-ID: <52A201F5-A78A-4E71-99F2-7ADA7E467B6E@akamai.com> References: <160624221011.1004.4337499034959566457@ietfa.amsl.com> <5FC76E4A.1000804@btconnect.com> In-Reply-To: <5FC76E4A.1000804@btconnect.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-02_08:2020-11-30, 2020-12-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 bulkscore=0 adultscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012020094 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-02_08:2020-11-30, 2020-12-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 spamscore=0 suspectscore=0 impostorscore=0 bulkscore=0 priorityscore=1501 phishscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012020094 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.18) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint1 Archived-At: Subject: Re: [ippm] [Last-Call] Last Call: (Data Fields for In-situ OAM) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 15:32:10 -0000 TGV0IG1lIGNvbW1lbnQgb24gdGhpcy4gSSd2ZSBiZWVuIG9uZSBvZiB0aGUgdGhyZWUgVExTIHJl Z2lzdHJ5IGV4cGVydHMgZm9yIGEgY291cGxlIG9mIHllYXJzLiBUTDtEUiBJIHRoaW5rIHRoZSBk cmFmdCBpcyBub3QgaW4gY29uZmxpY3Qgd2l0aCBob3cgdGhpbmdzIGFyZSBkb25lLg0KDQoNCu+7 v09uIDEyLzIvMjAsIDU6MzcgQU0sICJ0b20gcGV0Y2giIDxkYWVkdWx1c0BidGNvbm5lY3QuY29t PiB3cm90ZToNCg0KICAgIFRoaXMgSS1EIHNlZW1zIGF0IG9kZHMgd2l0aCBSRkM4MTI2IG92ZXIg dGhlIHVzZSBvZiBFeHBlcnQgUmV2aWV3IGluIHMuOC43DQoNCiAgICAnIFRoZSByZXNwb25zaWJs ZSBBRCB3aWxsIGFwcG9pbmh0IC4uLicNCiAgICBSRkM4MTI2IHNlZW1zIGNsZWFyIHRoYXQgdGhl IElFU0cgYXBwb2ludHMgYW5kIG1heSBkbyBzbyBpbiBhZHZhbmNlIGFuZCANCiAgICBoYXZpbmcg bW9yZSB0aGFuIG9uZSBpcyByZWNvbW1lbmRlZA0KDQpXZWxsLCB0aGUgQUQgaXMgcGFydCBvZiB0 aGUgSUVTRy4gRnJvbSB3aGF0IEkgaGF2ZSBzZWVuLCByZWdpc3RyeSBleHBlcnRzIGFyZSBhbHdh eXMgYXBwb2ludGVkIGJ5IHRoZSBBRCdzLCBhcyB0aGV5IGFyZSBleHBlY3RlZCB0byBiZSB0aGUg c3ViamVjdCBtYXR0ZXIgZXhwZXJ0cy4NCg0KICAgICd0aGUgZXhwZXJ0IHdpbGwgYXBwcm92ZSBv ciBkZW55Li4nDQogICAgUkZDODEyNiBzZWVtcyBjbGVhciB0aGF0IHRoYXQgaXMgdGhlIHJvbGUg b2YgSUFOQS4gIFRoZSBleHBlcnQgDQogICAgcmVjb21tZW5kcyBhbmQgaXQgaXMgdGhlbiB1cCB0 byBJQU5BIHRvIGFjdA0KDQpJQU5BJ3MgYWN0aW9ucyBhcmUgdXBkYXRpbmcgdGhlIHJlZ2lzdHJ5 LiBUaGUgZXhwZXJ0KHMpIHJlY29tbWVuZGF0aW9ucyBhcmUgYmluZGluZy4NCg0KPiAgICAndGhl IGV4cGVydCBjYW4gYXBwcm92ZSBhbGxvY2F0aW9ucy4NCiAgICBObywgdGhhdCBpcyB0aGUgcm9s ZSBvZiBJQU5BOyBlYXJseSBhbGxvY2F0aW9uIGlzIHBvc3NpYmxlIGJ1dCB0aGF0IGlzIA0KICAg IHRoZSBkZWNpc2lvbiBvZiBJQU5BLg0KDQpJZiB0aGVyZSdzIGFuIGV4cGVydCwgSUFOQSB3aWxs IGZvcndhcmQgdG8gdGhlIGV4cGVydChzKSBhbmQgYXNrIHdoYXQgdG8gZG8uDQoNCkkgdGhpbmsg cmVhZGluZyBTZWN0aW9uIDUganVzdGlmaWVzIG15IHZpZXdzIGFib3ZlLiAgUGVyaGFwcyA4MTI2 IGlzIG5vdCBpbnRlcm5hbGx5IGNvbnNpc3RlbnQgaW4gc29tZSBvZiB0aGVzZSBkZXRhaWxzLg0K IA0KDQo= From nobody Wed Dec 2 07:34:21 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FA53A133A; Wed, 2 Dec 2020 07:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JYlQ3dLQNuwj; Wed, 2 Dec 2020 07:34:17 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 18AA33A13BB; Wed, 2 Dec 2020 07:34:15 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0B2FY0l2002383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 Dec 2020 10:34:05 -0500 Date: Wed, 2 Dec 2020 07:34:00 -0800 From: Benjamin Kaduk To: "Salz, Rich" Cc: tom petch , "last-call@ietf.org" , "acm@research.att.com" , "ippm-chairs@ietf.org" , "draft-ietf-ippm-ioam-data@ietf.org" , "ippm@ietf.org" Message-ID: <20201202153400.GD64351@kduck.mit.edu> References: <160624221011.1004.4337499034959566457@ietfa.amsl.com> <5FC76E4A.1000804@btconnect.com> <52A201F5-A78A-4E71-99F2-7ADA7E467B6E@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52A201F5-A78A-4E71-99F2-7ADA7E467B6E@akamai.com> Archived-At: Subject: Re: [ippm] [Last-Call] Last Call: (Data Fields for In-situ OAM) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 15:34:20 -0000 On Wed, Dec 02, 2020 at 03:32:00PM +0000, Salz, Rich wrote: > Let me comment on this. I've been one of the three TLS registry experts for a couple of years. TL;DR I think the draft is not in conflict with how things are done. > > > On 12/2/20, 5:37 AM, "tom petch" wrote: > > This I-D seems at odds with RFC8126 over the use of Expert Review in s.8.7 > > ' The responsible AD will appoinht ...' > RFC8126 seems clear that the IESG appoints and may do so in advance and > having more than one is recommended > > Well, the AD is part of the IESG. From what I have seen, registry experts are always appointed by the AD's, as they are expected to be the subject matter experts. A single AD is tasked with finding volunteers to be expert(s), but the IESG as a whole approves them. -Ben From nobody Wed Dec 2 12:19:53 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C83F3A147E; Wed, 2 Dec 2020 12:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.59 X-Spam-Level: X-Spam-Status: No, score=-9.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=PSjBEG28; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TIpMVCNX 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 uSZdIzk_ypwM; Wed, 2 Dec 2020 12:19:42 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8073A147B; Wed, 2 Dec 2020 12:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=277537; q=dns/txt; s=iport; t=1606940381; x=1608149981; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6ap8u1tYuD7uepLU8NTIhBMb1I4+iSoYHb+vesBMPxw=; b=PSjBEG28oWPX8rei16hpYax5WpmaFVUEYzMz2FDtqwFweSbvj0ykeERl M96YN+5LOlAMWZHMKojFERa/6tQgStT8T0q9OxevBZuEdt1fhdIRNSjE9 WdK4N2KVtLvL0+SdN/csbpBITjOX1nNbB5rkgq0xSNIS5rqNl0rLgldWp I=; X-IPAS-Result: A0BDBABR9cdffZJdJa2FXbUVh1gIAwIPAwYEFQGNATrBe5Ec IronPort-PHdr: =?us-ascii?q?9a23=3AF4NRMBWVivV14gmJ6IHOLe4FJrHV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyHuf1BguvS9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7dp3Sz6XgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,387,1599523200"; d="scan'208,217";a="629091271" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Dec 2020 20:18:39 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B2KIduF011919 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2020 20:18:39 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Dec 2020 14:18:39 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Dec 2020 14:18:38 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 2 Dec 2020 15:18:38 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VGFV7Gov6RptBu0uXk5ORwiLrJSrCZX9Wqceu+Ofd8qH38BBTo6N02Ufrjsc+w3iMx2YMceE2nW/VzEygCgfuvIo6AN8VwAyxBa6EvdjDVz2sFYbQvISg9HVWCXedLRXh6IBHzEpLDVGetakztatZL1VjQI9zBGVLWCAyUP2xinznHCV5jx66fwP53COB+YOYyG21SBtRkkLeUz+Me8jSxCrOxTKj+2j/02K7NgqR1Gz8DK/clWImQvqkhgxN5Gb1iEVRcoU4JckZ+/lpy2rb2kS0wSeH7QD0UOkAzU7HePdp2i0zQCYblKTpfOpR+u4/LYZA/O/PGt7UpTmBtdKjA== 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=rel2tSbcB8p8NXXL9iGlu3+edkJGampZHwNBb/thT/8=; b=T6w1XqwWI0kHHZf/LRIRyX0PIpDPSx9oUz0LK2pRl6piUdIOsGXwAGQKO9G/8N+AFXWAHqI6gzqvM0lPM/UOvDYBhdggqlVA5DnxeQimWz7ZOAINUvg5pm2dS2+DAWfh1qCzf4uSzXVU/w3iDQOBT0HRYkzA7yuptZiB5lmAs6ZKA6nWlwpW8axXHvtNnis8ICXUvfGXnBYVsJPvrAWKinzkaBsTTu4u/Nx+r2FZimuJIUYd1uK01PIcrm0KWwdZyLIf0mf0S/eqLmBJn48+JUtHzn5ZWKLnfHosBOVWY4EBmPu507y5yzlHHlMfvAN+njqV2mJKnMrvnEgHbreOBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rel2tSbcB8p8NXXL9iGlu3+edkJGampZHwNBb/thT/8=; b=TIpMVCNXtzSM0qvm4VAFTGF6HU2SPWlpX9iN/ES51Y3ljZLWeT2Q0rcmh4xVO+r6566Z19otbFTUkVbhoy+aqlIK6ylYpf0Y2x7Gj5ElWBMWky9ieuCfWBHe5/nVDB2I5z0rR/MCd6nNIra/Pu/UL/s/teidOfVaN15tfcGYfBM= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM5PR11MB1355.namprd11.prod.outlook.com (2603:10b6:3:b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.18; Wed, 2 Dec 2020 20:18:35 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::b0:395a:1430:79d3]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::b0:395a:1430:79d3%5]) with mapi id 15.20.3611.031; Wed, 2 Dec 2020 20:18:35 +0000 From: "Rakesh Gandhi (rgandhi)" To: Greg Mirsky CC: Gyan Mishra , IETF IPPM WG , "James Guichard" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Greg Mirsky Thread-Topic: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: AQHWw1FAi8Q0V5FtjUGdBFDHCBkgBqnZreOIgAc3iICAA1dl0Q== Date: Wed, 2 Dec 2020 20:18:35 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1fed9b28-ad19-4194-ed30-08d896ff725f x-ms-traffictypediagnostic: DM5PR11MB1355: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: N9bs9zIWonaSKbIlsAPyCv1P61cjC2Ujic+4yIuy+XYEQN21ppGRqg3sOgFkWWK4qaIaQH4wBGEqZawgZfZ18yXBre+Jofx1WbwlL7NdeYzHqfIkYrdpcs4WLc/yy56DTRPBh8aYcyfd7zPq6RAqv2HZbLaPXUX4CItizytTWGDtE5NTw8zTORSCRNPpVqHfzpYM2DLlgQUyW6xdZ5s8KbAspns6en6bfMDqqSZrSQHvK68ujdyuNSTV3emQg08bixEU/6M1A6oViBOUU/+TcQ8CYkQZfVuCzvdeygR8nFPvrqu/B5I2zENne45x+blSGTN5VKiqKABGuvItTO4VB2EIuQ6XInfrUEiMMf/+0dMo3nSanPRBqgoUbHym2T0yyIqXAG+bD/yg/yeKCKQxuSEFF0n2oOTH29pnaR6Y3WY+X5xRItEJJj2BVrHBeoKw x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(376002)(366004)(136003)(396003)(478600001)(9686003)(4326008)(7696005)(52536014)(186003)(91956017)(76116006)(166002)(55016002)(53546011)(2906002)(86362001)(8676002)(6916009)(6506007)(8936002)(66476007)(66446008)(966005)(64756008)(33656002)(71200400001)(66556008)(66946007)(30864003)(316002)(26005)(5660300002)(83380400001)(54906003)(579004)(569008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?9B3cANixcWt+r4rpY8X/E9BH5oY4pDsFKH/sUm3pd36namGZCjath8aw?= =?Windows-1252?Q?ucUfWT3/afANxVDFMCJsqCrfgg7iQqy0y+ho8SeMXr3Srv51FSjpkzDI?= =?Windows-1252?Q?A1xtDDRWw5bdhnRJNF34ETZEW5p0cHdIAaQQIVZXA19Q+2bxKX2qGEFD?= =?Windows-1252?Q?rS2yIR5oqSsfzqYNOMdWCrRnAOK1B7titBRirLD05lKcFi5MUKS2s+sW?= =?Windows-1252?Q?bHTPVfiit92lS1oJX2N5+hzbhFJtV0/j7cXCazCUupXunhO2XzAlO9eL?= =?Windows-1252?Q?gpSs/gwkQWjwCZMvXRjgvxFCa1RvpDcjsUFLHxf/roxjW2bdfnOC84zi?= =?Windows-1252?Q?1cjWFsvfoYY2lD4s3HSwBze5AzD4F5LMC+oWC36nR6bwlY1Pk/uQdrPU?= =?Windows-1252?Q?cR/eXspNB4p+9i7fxipZ64KriIWYVuIZVcziLXxizhTdOx2xKokir+uR?= =?Windows-1252?Q?gN8HWyxia1nCY9RyZXsUZ9bP2OCvM4cNlTmgtpeQYzkw/wSOIcYXlX2N?= =?Windows-1252?Q?8An8iu/a7aGZprosi9ebAGpPdVjBtbdCdWga28eFkfrAa0MrDXhVsuYQ?= =?Windows-1252?Q?hBPc/0uSLInMDQ1KlLtbjDgtN3PAS0WUQHKmssxfmGq1SIzi+2ZPSwLM?= =?Windows-1252?Q?Nt3a0uuapZLTV4vqjSoOF6cswLRgK4Et64XP7Cx+QLhmmlE64XcIY1xn?= =?Windows-1252?Q?GJK4GNTFaOsxV4t7c1praGmmL/4x3PLB2lIDY54gThVvh+6eF8KQiw0v?= =?Windows-1252?Q?rLkDm6NdIvftxMqGcDFqHZ8uhmnzgU4J9fFSH2xn5nAhn4T0lJ5lDX/T?= =?Windows-1252?Q?VsqDg5aBeA+v8WJYDQRYfjaHs07tQB0QHMLWea+XvJv9QcZAOKONmPr6?= =?Windows-1252?Q?xlH/kLYYqtN7y/6AaIQOz2VEYVPET476AGQAkBlE/Ej01anSWO62nnbK?= =?Windows-1252?Q?MACUJvso0FE+ez9svouxlDuTS1Zi1KOMEp1CPVhlP81ysNGDEw2vowJ4?= =?Windows-1252?Q?J5bxvVSxYYVOkmY1UlVpavOveOM+X8CLYOcf+Vj3UHLiY8PAUM5qcIhB?= =?Windows-1252?Q?XHOje+FdRb1V9DOIxBIkXKahQ1Fq/RzM+FElTA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB31156BE924B8DF1F37E159BEBFF30DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1fed9b28-ad19-4194-ed30-08d896ff725f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2020 20:18:35.1132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CBQRyKBgG7COWzZsIarGbNqWv8XwBSsBdvdQh4fb9OulZ8BaujWTtn37tNaCwFOAHIofhq5lX38vLTppZ1gxNA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1355 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 20:19:49 -0000 --_000_DM6PR11MB31156BE924B8DF1F37E159BEBFF30DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Greg for your further reply and the discussions. Good to know that you do see a need for the extensions for the direct-mode = packet loss detection and the authors are actively working on an alternate = methods using BFD (as you mentioned below). Please see replies inline with =85. From: Greg Mirsky Date: Monday, November 30, 2020 at 11:30 AM To: Rakesh Gandhi (rgandhi) Cc: Gyan Mishra , IETF IPPM WG , Jame= s Guichard , ippm-chairs@ietf.org , spring-chairs@ietf.org , spring@ietf= .org , Greg Mirsky Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Hi Rakesh, thank you for the continued discussion. I appreciate your responses. I am s= till not convinced of the value these documents add. Please find my follow-= up notes in-line below under the GIM2>> tag. Regards, Greg On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) > wrote: Thank you Gyan and Greg for your review comments and discussions. Please se= e inline replies with =85 From: Gyan Mishra > Date: Wednesday, November 25, 2020 at 12:34 PM To: Greg Mirsky > Cc: IETF IPPM WG >, James Guichard >, Rakesh= Gandhi (rgandhi) >, ippm-chair= s@ietf.org >, spring-chairs@ietf.org >, spring@ietf.org > Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Hi Rakesh I have been following this thread and to help progress the discussion I wou= ld like to provide some comments in-line Gyan> Thanks Gyan On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky > wrote: Hi Rakesh, thank you for the response to my comments. Please find my follow-up notes i= n-lined below under the GIM>> tag. Regards, Greg On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Please see replies inline with =85 From: ippm > Date: Friday, November 6, 2020 at 11:18 AM To: James Guichard > Cc: spring@ietf.org >, ippm-chairs@ietf.org >, spring-chairs@ietf.org >,= IETF IPPM WG > Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Dear Chairs of the SPRING and IPPM WGs, Authors, et al., I've found myself in the situation when two related drafts are in the WG AP= s in the SPRING and IPPM WG (with the possibility that expertise from the t= hird WG, BFD WG, might be desirable to review the "liveness monitoring"). B= ecause these drafts are closely related, I've decided to combine my questio= ns and comments in a single thread. I hope that would be acceptable and con= sidered by the SPRING WG as well as IPPM WG. Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: * Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFC 4656 = and 5357 and introduce their own terminology for Session-Sender and Session= -Reflector. Also, many terms, e.g., Links, "congruent paths", are used in t= he documents without proper definitions. Other than that both drafts are re= adable and reasonably well-written. We are ok to change Sender to Session-Sender and Reflector to Session-= Reflector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. But I d= on't think that switching the terminology will fix the fundamental issue wi= th the proposal. The operation that is required from the remote entity, whe= ther it is referred to as responder or Session-Reflector, is not defined in= Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion, th= e behavior required, as described in the draft, cannot be characterized as = an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely new = protocol that, if there's a need in the new PM OAM protocol, must be proper= ly defined. Gyan> I am in complete agreement with Greg about terminology and consist= ency. The problem with inconsistency is that that you are not following we= ll known normative references required to understand the specification lead= ing to confusion and misunderstanding of the specification. The goal shoul= d be clear and concise in terminology and verbiage. Agree. Will address the terms from RFC 5357 in the next revision. There are many existing RFCs that use term =93Link=94 (e.g. RFC 5613, = 5340, 8330, etc.) and term =93Congruent Path=94 (e.g. RFC 5921, 6669) witho= ut defining them. I suspect it is because these are well-known terms. Havin= g said that, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . Is A-B-G-H-E-F congruent to it? From the definition of "congruent" as "tw= o figures or objects are congruent if they have the same shape and size, or= if one has the same shape and size as the mirror image of the other", it l= ooks as the path A-B-G-H-E-F is congruent to that SR tunnel. But a packet o= f an active OAM intended to monitor a flow over the SR tunnel is out-of-ban= d relative to that flow and will not produce any meaningful measurement. Of= course, for the case of the extensions in drafts *-twamp-srpm, direct loss= measurement can be performed, as information collected from node F and pac= kets that collect the counters are not required to be in-band with the moni= tored flow. So, this example, in my opinion, illustrates two of my concerns= : =95 using a congruent path for active performance measurement, e.g.= , TWAMP or TWAMP Light, may produce information that does not reflect the c= ondition experienced by the monitored flow. It seems that the terminology s= hould reflect the fundamental requirement of ensuring that active OAM test = packets are in-band with the monitored flow. =95 there are no technical requirements to justify using in-band te= st packets for direct packet loss measurement. In fact, using the in-band m= ethod for collecting in-profile counters leads to a waste of bandwidth, whi= ch may have a negative impact on services that require low-latency and/or l= ow packet loss. As demonstrated in this example, direct packet loss can be = performed using an out-of-band mechanism, e.g., SNMP queries, Netconf notif= ications based on YANG data model. * Does the document solve a real problem? No, it appears that these drafts define a new performance measurement proto= col for the purpose of combining OWAMP and TWAMP functionality and adding t= he ability to collect counters of "in-profile" packets. I couldn't find suf= ficient technical arguments for using a PM protocol instead of, for example= , extending the existing OAM mechanisms like ICMP. Gyan> This may sound basic but is a very critical subject going down the = same lines of clarity in verbiage so their is no misunderstanding. =93Cong= ruent=94 by definition means shape of an object and if you super imposed tw= o objects on top of each other they fit perfectly and the edges coincide id= entically. The problem with congruent is that it is based on the shape and= that shape could be a mirror image or reflection which may not be exact. = So when referring to a SR-TE path taken this could lead to confusion as to = path taken if it=92s the same path or congruent which is vague as to =93exa= ctly=94 which path is taken where here there is criticality as to the path = being referenced in terms of in-band versus out-of-band. I agree that for = direct in band packet loss measurement can be done via existing OAM mechani= sme via ICMP. Ok, we will find an appropriate term for =93sending packets on the sa= me path as data traffic=94. Extending ICMP for direct-mode loss measurement is outside the scope = of this draft. But good to see the agreement for the direct in band packet = loss measurement to be done (albeit by some other means). GIM2>> I feel that you misunderstand my position in regard to the use case = these four documents try to solve. I don't recall that I've stated that "di= rect in-band packet loss measurement" requires any additional standardizati= on work. The Direct Measurement TLV has solved that for STAMP and draft-iet= f-ippm-stamp-option-tlv is now in the RFC Editor's queue. I cannot find any= valid technical reason to re-open this and measure the direct packet loss = in a slightly different way. I must point out that a claim that using fixed= positions for the direct packet loss optimizes performance does not stand = for cases (Section 4.2.1 and 4.2.2 of draft-gandhi-spring-stamp-srpm) when = the return path is specified in the Return Path TLV and, as I understand it= , in some cases even the second TLV, Node Address TLV, is used. Thus, it is= clear that the proposed new method of direct packet loss measurement does = not offer any significant benefits comparing to the STAMP's Direct Measurem= ent TLV and appears nothing but superfluous. The direct-mode packet loss use-case is typically for the forward dir= ection packet loss. And this does not use the return path TLV. We can clari= fy that in the draft. There is a requirement to measure performance delay as well as synthet= ic and direct-mode packet loss in segment-routing networks. OWAMP and TWAMP= protocols are widely deployed for performance delay and synthetic packet l= oss measurement today. I am not sure extending ICMP for LM is a good option= here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP for exclusive = direct packet loss measurement. Gyan> Agreed There is definitely a need to do direct-mode loss measurement in IP/S= R networks, as RFC 6374 mechanisms are for MPLS networks. Note that there w= as an attempt to extend BFD for direct-mode loss measurement for this purpo= se using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-0= 3). GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense.= The work and discussion of the proposal continues and the new version will= be published soon. Ok, so you do see a need for the extensions for the direct-mode packe= t loss detection and the authors are actively working on an alternate metho= ds using BFD. * Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocol on network security, to comprehensively evaluate the proposed= solution. About your comment on zero checksum, this is described in Security sec= tion in RFC 6936. We will add reference to this RFC in our Security Section= as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Gyan> Agreed 0 UDP MIMA security threats and that you need to thorough= vetting of RFC 6936. Yes, will add in the next revision. Hope we can work together on nee= ded text. To summarize my review of these two drafts: * these propose a new protocol, not an update or enhancement of the TWA= MP-like protocol; The probe and response messages defined in [RFC 5357] are used for del= ay measurement and synthetic packet loss. The direct-mode packet loss messa= ges are defined in draft-gandhi-ippm-twamp-srpm that match these delay measurement mes= sages. As stated, draft-gandhi-ippm-twamp-srpm defines =93extensions=94 for TWAMP Ligh= t. GIM>> I cannot find where RFC 5357 defines "the probe and response messages= ". Could you give a more specific reference or provide the text that, in yo= ur opinion, defines such messages? But I'm more concerned with the directio= n of "extending" non-protocol referred to as "TWAMP Light". As a contributo= r to BBF's TR-390, I'm have learned how different are existing implementati= ons of TWAMP Light. And that is also noted in EANTC Multi-Vendor Interopera= bility 2019 white paper. The status of TWAMP Light is explain= ed in RFC 8545 and I cannot see that it can be used as a foundation of any = standard. Gyan> I don=92t see the probe a d response messages in TWAMP RFC 5357 Agree to use term test-packet from RFC 5357. =B7 several parts of the proposed protocol, e.g., Zero UDP checksum= in IPv6, require detailed security analysis, which is currently absent; Gyan> Agreed Please see previous reply. This is specified in RFC 6936 Security Section. We will add reference = to this RFC in our Security Section as well. This is only specific to the U= DP port locally provisioned in the domain by the operator for TWAMP. GIM>> I've noted above that a simple reference does not sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol. I believe that the proposal = to use zero UDP header checksum requires extensive analysis, using the anal= ysis provided in RFC 6936. Gyan> Completely Agree Please see previous reply. * I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on t= he Informational track even though it is essential to the new protocol as i= t defines its key elements This was to address your previous comment quoted as: =93- as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea is described in the informational text only, I think that the Informational track is more appropriate for this specification.=94 https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ Having said that, we are ok to change to PS. GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. If= anyone is interested in standardizing an "extension", I'd expect that they= first define the base specification to which the extension applies. I migh= t have missed the definition of TWAMP Light protocol in the draft. Could yo= u point to the definition, for example, of the Authenticated mode in TWAMP = Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? Gyan> Agreed The Appendix I of RFC 5357 does have information on the Authenticatio= n mode. As specified there, this is based on user configured parameters. =B7 I believe that draft-gandhi-spring-twamp-srpm should be anchore= d at IPPM WG as it does introduce the new PM protocol. The TWAMP Light extension draft-gandhi-ippm-twamp-srpm is already in IPPM WG. The= SPRING draft only defines SR PM procedures. Below, please find my detailed comments, questions on these drafts: * draft-gandhi-spring-twamp-srpm I have several questions about the relationships between this draft and App= endix I in RFC 5357 where the idea of a mode known as TWAMP Light has been = mentioned. The nature of the TWAMP Light and what is required to make it a = standard is well-explained in Section 4 of RFC 8545 (apologies for the long quote): "TWAMP Light" is an idea described in Appendix I ("TWAMP Light (Informative)") of [RFC5357]; TWAMP Light includes an unspecified control protocol combined with the TWAMP-Test protocol. In [RFC5357], the TWAMP Light idea was relegated to Appendix I because TWAMP Light failed to meet the requirements for IETF protocols (there are no specifications for negotiating this form of operation and no specifications for mandatory-to-implement security features), as described in Appendix A of this memo. See also [LarsAD] and [TimDISCUSS]. Since the idea of TWAMP Light clearly includes the TWAMP-Test component of TWAMP, it is considered reasonable for future systems to use the TWAMP-Test well-known UDP port (whose reallocated assignment is specified in this document). Clearly, the TWAMP Light idea envisions many components and communication capabilities beyond TWAMP-Test (implementing the security requirements, for example); otherwise, Appendix I of [RFC5357] would be one sentence long (equating TWAMP Light with TWAMP-Test only). Since we don't have an IETF document that addressed these open questions, = I don't think we can have a draft that proposes extensions to a non-standar= d mechanism (Appendix is for Informational material, as I understand it) on= the Standard track. Gyan> Agreed The procedure for using the RFC 5357 defined messages in TWAMP Light = configuration mode is defined in the corresponding spring drafts. It also d= escribes the provisioning model. GIM2>> If a return path can be provisioned for TWAMP Light, why the same me= thod of controlling a test session cannot be used for STAMP? It is not expected that all STAMP TLV extensions need to be supported= for TWAMP Light using provisioning. This was to address your previous comment quoted as =93- as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea is described in the informational text only, I think that the Informational track is more appropriate for this specification.=94 https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ Having said that, we are ok to change to PS as you mentioned above. BTW, despite only difference of fixed vs. variable length payload in S= TAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it = uses the same approach of provisioning as defined in this draft). Hence, s= ecurity considerations for STAMP and TWAMP Light are not different. Note th= at both STAMP and TWAMP Light have authenticated messages defined for Secur= ity purpose. GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the li= ght, simpler, version of TWAMP-Test component of TWAMP protocol. I cannot f= ind in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode = of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the dis= cussion of "extension" to TWAMP Light. The Authentication information is user-configured as shown in Section= 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described in Append= ix I of RFC 5357. Now a number of more specific questions. draft-gandhi-spring-twamp-srpm: * In the Introduction it is stated that: The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides simplified mechanisms for active performance measurement in Customer IP networks by provisioning UDP paths and eliminates the need for control-channel signaling. I can not find where, either Appendix I or TR-390, "eliminated the need for= control-channel signaling". Also, could you point where the referenced doc= uments describe "provisioning UDP paths"? The Appendix I of RFC 5357 has following text. We can reword and match= the exact text if you prefer. =93This example eliminates the need for the TWAMP-Control protocol, and assumes that the Session-Reflector is configured=94 GIM>> I think that the text you're proposing is even more confusing. It is = not clear which example the sentence is referring to. Also, what is the bas= is for such an assumption? This is the exact text from RFC 5357 Appendix I. Please go through th= e entire Section in that RFC 5357 to avoid =93out of context=94 discussion. * It appears that the last paragraph in the Introduction describes the = relationship with Appendix I of RFC 5357: The procedure uses the mechanisms defined in [RFC5357] (TWAMP Light) and its extensions for Performance Measurement. I think that the reference must be to Appendix I, not RFC 5357. Also, could= you please specify which extensions of TWAMP Light have been used in this = draft? We can add the Appendix I as reference in the next revision. Extension= s are defined in draft-gandhi-ippm-twamp-srpm, we can add this reference. GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a nor= mative reference while it is, by its nature, an Informational document. If approved, it is fine to have informational draft/RFC in a normativ= e reference. But RFC 5357 is PS. * In Section 2.3 describing the reference model is noted: The probe response message is typically sent to the sender node R1. In which scenarios the reflector acts differently? How such behavior is rel= ated to the behavior of a TWAMP Session-Reflector, as defined in RFC 5357? Do you prefer we remove =93typically=94 from the sentence? GIM>> If that fits into the operational model of the new protocol you're de= fining. * Also in Section 2.3 a Link is mentioned as an element directly connec= ting nodes in the presented reference model. Could you clarify what is a Li= nk? Is it always a physical connection between two systems or a virtual? Both, please see Section 4.1.3. =93Link=94 is well known term used in = many existing RFCs (please see RFC 5613, 5340, 8330). GIM>> Thank you for the references. I couldn't find a definition of an obje= ct "Link" (capitalized) but only "link" (lower case). Hence, since the draf= t consistently uses the capitalized form, I consider it to be something els= e, something different from a link. Ok, we can change Link to link in the next revision to avoid confusio= n. * In Section 3 behavior of the reflector described as ... no PM state for delay or loss measurement need to be created on the reflector node R5. That is in contradiction to the behavior of a TWAMP Session-Reflector as de= fined in RFC 5357. Could you provide a reference to an IETF standard where = this behavior is defined? Also, how, without creating a state at the Sessio= n-Reflector, to achieve one-way delay and synthetic loss measurement on a b= idirectional SR tunnel? Gyan> Valid point Bidirectional SR tunnel may have an SR state but the statement above = is that no PM (i.e. TWAMP Light) protocol session state is created for it. = We can clarify in the next revision. GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one opt= ion. I am well-familiar with the implementation that uses the stateful mode= . What information stateful PM need to maintain in the state on the ref= lector? Doesn=92t that cause scale issues. We can add in the draft you if t= here is anything specifically needed in the spec. Quoting the text from Appendix I in RFC 5357. We can quote the text a= s is. =93In the case of TWAMP Light, the Session-Reflector does not necessarily h= ave knowledge of the session state. =93 GIM>> By the informational nature of Appendix I, the text is not normative.= I am familiar with the implementation of TWAMP Light which does maintain t= he session state and thus supports one-way packet loss measurement. If you = require that the remote node does not maintain the state, the draft must de= fine that as part of the specifying the behavior of the protocol. Ok, we can discuss what information is to be maintained in that stat= e on the reflector for synthetic packet loss. We can add appropriate text i= f you can help please. GIM2>> I don't see any reason to do that as that already defined in RFC 876= 2 and draft-ietf-ippm-stamp-yang Ok. =B7 Further, in Section 3 the selection of UDP port explained as th= e following: As specified in [RFC8545], the reflector supports the destination UDP port 862 for delay measurement probe messages by default. This UDP port however, is not used for loss measurement probe messages. To the best of my understanding, as one of the contributors and Editors of = RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflector= without excluding any type of measurement. Besides, in TWAMP delay and pac= ket loss are measured in the same test session, using the same flow of TWAM= P-Test packets. Gyan> Agreed Yes, we can use port 862 for both delay and synthetic packet loss =96= they are using the same test packet. There is no change proposed in the dr= aft. GIM2>> Packet delay and synthetic packet loss measurements are already supp= orted in RFC 8762. Are you proposing a new protocol to duplicate the STAMP = functionalities? As mentioned, the extensions defined are for the direct-mode packet l= oss measurement for TWAMP Light and STAMP. The packet loss in existing RFC 5357 refers to synthetic loss as there= is no support for direct-mode loss in RFC 5357. We can change the text to = clarify as =93This UDP port however, is not used for direct-mode loss measu= rement probe messages.=94 GIM>> I've found that there's some misconception in the draft. RFC 8545 re-= assigned UDP port 862 not for "delay measurement probe messages" but for TW= AMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, pac= ket loss, reordering (RFC 4737 defines packet reordering metric), and packe= t duplication measurement. * Then the draft states that The sender uses the UDP port number following the guidelines specified in S= ection 6 in [RFC6335]. Could you point to the guidelines that a user can use when selecting a UDP = port number of a test session? Gyan> Good point Please see section 6 in [RFC6335]. We can cite the range which will be= the same as used in [RFC8762]. This was also discussed earlier. https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ GIM>> I've looked through Section 6 but I don't find anything specifically = applicable to this draft we're discussing. If the protocol to use UDP port = numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it= seems that stating that explicitly would be the best way. This would be, User Ports and Dynamic Ports ranges, which are defined= in [RFC6335]. Yes, we can add this te= xt. * At the closing of the paragraph, we read that The number of UDP ports with PM functionality needs to be minimized due to limited hardware resources. Does a UDP port number pose PM functionality? How it is assigned to the por= t number? UDP ports are user configured for delay and direct-mode loss PM as des= cribed in Section 3.1. GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss measur= ement uses port number different from the one used by a TWAMP-Test packet, = in my opinion, is another indication that this is the definition of a diffe= rent from TWAMP Light PM OAM protocol. If we add a field in the packet then UDP port 862 may be used along w= ith the new field. But it will require extra processing in hardware. It is = better to use a different UDP port for processing efficiency in hardware. * Following the above-quoted text, in Section 3 is noted: For Performance Measurement, probe query and response messages are sent as following: Could you clarify if the listed further procedures deviate from OWAMP/TWAMP= or follow procedures defined in RFC 4656 and RFC 5357 for Session-Sender a= nd Session-Reflector respectively? Probe messages follow the same procedure as defined in RFC 4656 and RF= C 5357. GIM>> All messages, i.e., TWAMP-Test packets as well as the defined in draf= t-gandhi-ippm-twamp-srpm? Yes, unless otherwise specified in the draft-gandhi-ippm-twamp-srpm. * for both delay and loss measurements draft requires test packet be tr= ansmitted on a congruent path: the probe messages are sent on the congruent path of the data traffic by the sender node It is not clear what "the congruent path" means. The definition of congruen= cy in geometry tells us that an object B is congruent to object A if it has= the same shape and size, but is allowed to flip, slide or turn. How a path= can be congruent to another path? Gyan> Agreed. The use of congruent in the context of pathing is con= fusing as the path being addressed may not be reflected accurately by the t= erm congruent. As replied above. There are many existing RFCs that use term Congruent Path (e.g. RFC 59= 21, 6669) without defining them. I suspect it is because it is well-known t= erm. Having said that, we can add a reference for it if it helps reader. GIM>> I cannot assume what was the context of these RFCs. I've sketched a n= etwork diagram above to illustrate that a "congruent path" may well lead to= out-of-band path. Is that the intention of the authors of the draft to use= this protocol out-of-band? As replied above. * The last paragraph in Section 3 refers to work on iOAM: The In-Situ Operations, Administration, and Maintenance (IOAM) mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM information such as timestamp in-band as part of the data packets, and are outside the scope of this document. Is iOAM in the scope of this specification? What are the relationships betw= een iOAM and draft-gandhi-spring-twamp-srpm? As mentioned in the draft, IOAM is outside the scope. GIM>> Yes, but it appears that references to the two IOAM-related drafts ha= ve some purpose. What is it? How are these drafts related to draft-gandhi-s= pring-twamp-srpm? We can remove them if it is confusing. It is informational text (was = added to address a review comment). * Section 3.1 presents an example of the provisioning model but puts th= e definition of the provisioning model outside the scope. Is there an accom= panying specification that defines the provisioning model that can be used = in multi-vendor deployment? Could that be YANG data model? What is the rela= tionship with draft-ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented? Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yang<= https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> and add any miss= ing items in a separate draft. We can also add a reference in this draft. GIM>> I think that theremust be some discussion on how the new protocol is = configured. If TWAMP YANG data model can be augmented, I'd expect that bein= g defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything abo= ut the configuration of the protocol. The Yang model extensions are not in the scope of this draft * Section 4.1 states that a new message is introduced to perform the Lo= ss Measurement in this protocol Why the capability of TWAMP to measure the = loss in one-way and two-way is not sufficient? Existing TWAMP messages do not support =93direct-mode=94 loss measurem= ent. We can add =93direct-mode=94 in the text to clarify. GIM>> True, direct loss measurement, in fact, is not active measurement and= thus is outside the scope of Two-Way Active Measurement Protocol (TWAMP). = The direct-loss measurement is, by the definition of RFC 7799, passive meas= urement method and fetching counters can be done using numerous methods, e.= g., SNMP, Netconf RFC 7799 does not say using Test-packets to collect counters for dire= ct-mod loss measurement is passive. GIM2>> Per RFC 7799, injecting in-band test packets is the characteristic o= f an active measurement method. Using out-of-band transport, e.g., SNMP que= ries, would be an example of a passive measurement method. Ok, so you answered your own question that the direct-mode packet los= s extension defined is =93active measurement=94 method. * Section 4.1.1 requires that The Destination UDP port cannot be used as Source port, since the message does not have any indication to distinguish between the query and response message. Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain? Gyan> Good question Yes, it is unique in the domain. This is user-defined and is up to the user what UDP port to provision = in a domain. GIM>> So, can user configure a port number from the User Ports range? Or, c= an the same port number be used on the same system for a number of test ses= sions? I find the use of UDP port numbers being underspecified. * Section 4.1.2 of RFC 5357 does not define "the delay measurement mess= age" but refers to the definition of the Session-Sender's test packet in RF= C 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet for= mat to perform both delay and packet loss measurement. Ok, we can update the text in the next revision to indicate exact name= from the RFC 4656. We can also add text to include synthetic packet loss. GIM>> I think that making it explicit would help. Also, that will highlight= what is being introduced by *twamp-srpm drafts is, in fact, a new protocol= to perform synthetic packet loss measurement. No, it does not change anything for synthetic packet loss. * Can you explain how "the DM probe query message contains the payload = format defined in Section 4.2.1 of [RFC5357]" when the referenced section o= f RFC 5357 defines the format of a Session-Reflector's test packet? We can update the text in the next revision to indicate query format n= ame from RFC 5357. GIM>> I cannot find any reference to a query format in RFCs 4656/5357. Coul= d you please quote from any of these documents? It is test-packet, we will use RFC 5357 term. * Can clarify the applicability of RFC 6038 and the symmetrical packet = size? Is it required? Can it be non-symmetrical? Yes. Please see section 4.1.1 and quoted below: =93For symmetrical size query and response messages as defined in [RFC6038]= ,=94 GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the sym= metrical test packets. Since *-twamp-srpm proposals do not use TWAMP-Contro= l protocol and Appendix I in RFC 5357 tells us nothing about that either (i= n part because RFC 6038 came later), I don't see that there's any certainty= in what is the sze of a test packet used in the direct-loss measurement. The test-packets as defined in these existing RFCs are used for dela= y and synthetic packet loss. The direct-mode test-packets are defined in th= is draft. GIM2>> This draft defines only a new packet format for the direct packet lo= ss measurement. For STAMP such a mechanism is clearly superfluous given the= Direct Measurement TLV is already defined. As replied earlier. * Can you clarify the use of the timestamp format, NTP or PTPv2? It is = not clear which is the default, mandatory or optional. This is same as TWAMP. There is no change. GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for *-twam= p-srpm? No change in existing in what is there in RFC 5357 and RFC 8186. * Also, is "hardware support in Segment Routing networks" of the PTPv2 = format required, guaranteed, or something else? Hardware timestamps are recommended for SR use-cases. We can change th= e sentence. GIM>> Perhaps you can propose some text, that would be helpful. Ack. * Section 4.1.1.1 stated that A separate user-configured destination UDP port is used for the delay measurement in authentication mode due to the different probe message format. Can that be interpreted that there could be concurrent authenticated and un= authenticated test sessions using this protocol? Would different authentica= tion methods require using unique destination UDP port numbers? Yes, and Yes, and these are based on provisioning. GIM>> But that requirement is far outside the TWAMP, as defined in RFC 5357= . Some Session-Sender can use authenticated and some not. It is part o= f RFC 5357. * Section 4.1.2 by introducing the dedicated Loss measurement packet fo= rmat, effectively modifies the behavior defined in RFC 5357 for Session-Sen= der and Session-Reflector. But the document does not state that. Can you cl= arify whether this specification changes the behavior of a Session-Sender a= nd Session-Reflector as defined in RFC 4656 and RFC 5357 respectively for t= he support of packet loss measurement? The direct-mode loss defines new procedure for sender/reflector to col= lect traffic counters, as opposed to timestamp. The rest is the same as RFC= 4656 and 5357. GIM>> I cannot agree with your statement " The rest is the same as RFC 4656= and 5357" because the sender's direct-loss format does not have Error Esti= mate field, Thus, a reflected packet does not have Sender's Error Estimate,= nor Error Estimate of the reflector. And that, in my opinion, is another c= lear indication that *twamp-srpm drafts define a new protocol, separate fro= m OWAMP/TWAMP. That field is specific to timestamps and would not apply to counters= for direct-mode loss measurement. * And a similar question about the use of the separate UDP port number = for the authenticated of the packet loss measurement. * A couple of question to the following text in Section 4.1.3: The local and remote IP addresses of the link are used as Source and Destination Addresses. They can also be IPv6 link local address as probe messages are pre- routed. * What are the addresses of a link? I am assuming this well-known (e.g. RFC 2328). GIM>> I am not familiar with the term "pre-routed". What does it mean? Ensure that packets are routed over the link. * In which scenarios an IPv6 LLA can be used? I am assuming this is well-known (e.g. RFC 5613). GIM>> So, LLA may be used as the source and destination addresses when test= ing an SR tunnel? As mentioned this is for links. * Also, could the use of a routable destination IP address be used a= s a DDOS attack vector? Consider the scenario when an attacker generates SR= -encapsulated packets with the destination IP address other than any of the= SR-terminating nodes. Such a packet will be routed, correct? That does app= ear as a security threat, would you agree? Absolutely do not agree. It is no different than IP routed TWAMP packe= t as defined in [RFC5357]. GIM>> You don't agree that the processing described cannot happen because o= f laws of physics or it wouldn't happen because no one will think of that? = If the latter, I think that that is security threat. There is no new threat like you have mentioned. GIM2>> Hmmm, but how the integrity of TLVs proposed in draft-gandhi-ippm-st= amp-srpm can be protected? These are not protected by HMAC as presented in = figures 3 and 5. The extensions do not change the processing of these existing TLVs de= fined for HMAC. We can add text to indicate this. * Section 4.1.4.2 references Figure 5 that, as I understand it, display= s the format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflecto= r's reflected packet. Which of the two is used for the delay measurement in= the proposed protocol? The probe query packet in the Session-Sender text packet. We can updat= e the name. * Section 4.2.1 states that In one-way measurement mode, the probe response message as defined in Figure 6 is sent back out-of-band to the sender node ... Could you clarify how the responder controls that the response packet is se= nt not in-band but out-of-band? Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This is = existing behaviour for out-of-band. GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines another= new protocol OWAMP Light. And it is not clear what you reference as "this = is existing behavior". Is it to reference behavior of TWAMP test packet? Bu= t the behavior of the TWAMP-Test protocol by itself is neither in-band, nor= out-of-band. It is the encapsulation of the TWAMP test packet that makes i= t either in-band or out-of-band. Right. * How's the method described in Section 4.2.3 is different from the met= hod described in RFC 8403? What is dis= tinctly unique about the loopback mode proposed in the section? There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403. GIM>> So, you believe that proposing to use the method described in RFC 840= 3 for the TWAMP packet is innovation? And what are the benefits of using th= e TWAMP test packet format in the Loopback mode? Please see the draft. * What is the rationale for setting TTL/Hop Limit fields always to 255 = for IPv4, MPLS, and IPv6 (per Section 4.3.1)? This is as defined in Section 4.2 of RFC 5357 (Bullet 4). GIM>> I believe you've misunderstood the text in RFC 5357. This bullet spec= ifies the behavior of a Session-Reflector. It is to try to read TTL value o= f the received TWAMP test packet and copy the value in Sender TTL field of = the reflected packet. If the Session-Reflector cannot access the TTL field,= it MUST write 255 in the Sender TTL field. So, I think that my questions s= till remains. Please see Section 4.2.1 of RFC 5357. * Section 4.3.3 states that a zero-value UDP checksum may be used in so= me scenarios. RFC 8085 allows that but in very specific cases that are docu= mented in detail in Section 3.4.1. Do you believe that the case of this pro= tocol checks all the requirements for allowing the use of Zero UDP checksum= as specified in RFC 8085? Also, I believe that allowing the use of Zero UD= P checksum in some scenarios, this protocol introduces a security threat th= at must be thoroughly analyzed in the Security Considerations section. This is described in RFC 6936. It will be very specific to the UDP por= t provisioned for TWAMP. We will add reference to RFC 6936 in Security Sect= ion. GIM>> I don't think that the reference is sufficient for the Securit Consid= eration. I'd expect some extended discussion on why using zero UDP header c= hecksum is not a security threat for *twamp-srpm protocol. Please see reply above. * Section 8 refers to "liveness monitoring of Links and SR Paths". This= appears as the replication of functionality provided by BFD/S-BFD protocol= s. Is such comparison accurate? If it is, shouldn't the proposal be also re= viewed by the BFD WG? TWAMP probe messages are used today for synthetic packet loss which c= an also be used to detect connection loss (performance metric). The section= simply highlights this obvious metric. GIM>> Can you point to a document that has defined "TWAMP probe messages a= re used today for synthetic packet loss"? Also, which document defines loss= of connectivity as a performance metric? Does *twamp-srpm proposes to use = the new protocol to detect the loss of path continuity? For example Y.1731 has such notion of connection loss. TWAMP is used= widely for synthetic packet loss and is well-known. There is no change in = protocol. This is reported metric. GIM2>> What are packet transmission frequencies authors envisioned for that= mode? A single-digit millisecond? It depends on the implementation. * I found the Security Section of the proposed protocol inadequately te= rse and missing very important threats that this protocol introduces in the= network. Other than referring RFC 6936 for zero checksum what else is missing? = Otherwise it is no different than RFC 8762 (STAMP). GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The use = of source IP addresses, as mentioned above, appears to be another security = risk introduced by *-twamp-srpm drafts. There is no mention of Source IP address above. * draft-gandhi-ippm-twamp-srpm As I understand it, the motivation for the Loss Measurement mode defined in= this specification is to collect "in-profile" counters. Is that correct? D= o you see as essential for this mode that the query messages are in-band wi= th the flow being profiled? In your opinion, how using an out-of-band metho= d of collecting these counters, e.g., by using ICMP multi-part message exte= nsion per RFC 4884, could affect the accuracy comparing with the method in = this protocol? How the impact changes if extended ICMP messages are in-band= with the profiled flow? Yes, they need to be in-band with the flow, to collect the counter f= rom the right forwarding paths for the flow. Discussion of using ICMP for d= irect-mode loss measurement is outside the scope of this draft. GIM2>> I think that the assumption "they need to be in-band with the flow, = to collect the counter from the right forwarding paths for the flow" is tec= hnically inaccurate. Otherwise, how SNMP queries could work for decades of = networking history? The scope of this draft is orthogonal to the out of band schemes thos= e may exist. Thanks, Rakesh As mentioned earlier, I am not sure extending ICMP to do PM is a good = option here. Both TWAMP and OWAMP are widely deployed today for delay and s= ynthetic loss measurement. GIM>> What is the reason mentioning OWAMP? Are drafts *-twamp-srpm extend R= FC 4656 OWAMP as well? Also, what you see as the connection between using a= ctive measurement methods to measure packet delay and packet loss, on one h= and, and collecting packet counters? The Session-Sender test-packet is defined in OWAMP RFC and not TWAMP = RFC. Other than timestamp and its format vs. counter and its format, the me= ssages and processing are the same. Thanks, Rakesh * Section 3.1 introduces the new field, Sender Control Code. The format= of the packet, as I understand it, is presented in Figure 1. When comparin= g with the format of Session-Sender's test packet defined in RFC 4656 OWAMP= in Section 4.1.2 I've noticed that there are no MBZ fields. Are these intr= oduced by your proposal? It shows the partial message that has new field. We can update it to s= how the full message to avoid such confusion. * Also, it appears that the Sequence Number field in TWAMP Session-Send= er's test packet is absent in Figure 1. Is that intentional? It shows the partial message that has new field. We can update it to s= how the full message to avoid such confusion. Thanks, Rakesh Regards, Greg Thanks Gyan On Thu, Oct 22, 2020 at 5:51 AM James Guichard > wrote: Dear WG: This message starts a 3 week WG adoption call for document https://tools.ie= tf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 12th 2020. Pl= ease note that this document has several changes from v-10 that were reques= ted by the SPRING and IPPM chairs. For this reason, the chairs have extende= d the adoption call for an additional week to allow the WG enough time to r= eview these changes before deciding on WG adoption. Some background: Several review comments were received previously for document https://tools= .ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chair= s considered those comments, and upon review of this version of the documen= t, determined the following: * The SPRING document should describe only the procedures relevant to S= PRING with pointers to non-SPRING document/s that define any extensions. Se= veral extensions including Control Code Field Extension for TWAMP Light Mes= sages, Loss Measurement Query Message Extensions, and Loss Measurement Resp= onse Message Extensions were included in https://tools.ietf.org/html/draft-= gandhi-spring-twamp-srpm-10 and should be removed from the SPRING document. * The TWAMP extensions included in https://tools.ietf.org/html/draft-ga= ndhi-spring-twamp-srpm-10 should be described in a new document published i= n the IPPM WG. These conclusions were discussed with the authors of https://tools.ietf.or= g/html/draft-gandhi-spring-twamp-srpm-10 the result of which is the publica= tion of the following two documents: * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The su= bject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This doc= ument will be progressed (if determined by the WG) within the IPPM WG. After review of the SPRING document please indicate support (or not) for WG= adoption to the mailing list. Please also provide comments/reasons for tha= t support (or lack thereof) as silence will not be considered as consent. Finally, the chairs would like to thank the authors for their efforts in th= is matter. Thanks! Jim, Bruno, & Joel _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD --_000_DM6PR11MB31156BE924B8DF1F37E159BEBFF30DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thank you Greg for you= r further reply and the discussions.

Good to know that y= ou do see a need for the extensions for the direct-mode packet loss detecti= on and the authors are actively working on an alternate methods using BFD (= as you mentioned below).

Please see replies inl= ine with <RG3>=85.

 

 

From: Greg Mirsky <gre= gimirsky@gmail.com>
Date: Monday, November 30, 2020 at 11:30 AM
To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, IETF IPPM WG <ippm= @ietf.org>, James Guichard <james.n.guichard@futurewei.com>, ippm-= chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs@ietf.org <sp= ring-chairs@ietf.org>, spring@ietf.org <spring@ietf.org>, Greg Mirsky <gregory.mirsky@ztetx.com>
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf= .org/html/draft-gandhi-spring-twamp-srpm-11

Hi Rakesh,

thank you for the continued discussion. I appreciate= your responses. I am still not convinced of the value these documents add.= Please find my follow-up notes in-line below under the GIM2>> t= ag.

 

Regards,

Greg

 

 

On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

Thank you Gyan and Greg for your rev= iew comments and discussions. Please see inline replies with <RG2>=85=

From: Gyan Mishra <hayabusagsm@gmail.c= om>
Date: Wednesday, November 25, 2020 at 12:34 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com&g= t;, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

 Hi Rakesh 

I have been following this thread and to help progress the discuss= ion I would like to provide some comments in-line Gyan> =

Thanks

Gyan

On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <gregimirsky@gmail.com> wrot= e:

Hi Rakesh,

thank you for the response to my comments. Please find my fol= low-up notes in-lined below under the GIM>> tag. 

Regards,

Greg

On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> = wrote:

Thank you Greg for taking time for thoroughly= reviewing the documents and providing the comments.

Please see replies inline with <RG>=85<= /span>

From: ippm <ippm-bounces@ietf.org&= gt;
Date: Friday, November 6, 2020 at 11:18 AM
To: James Guichard <james.n.guichard@futurewei.com>
Cc: spring@ietf= .org <spring@ie= tf.org>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Dear Chairs of the SPRING and IPPM WGs, Authors, et al.,

I've found myself in the situation when two related drafts are in = the WG APs in the SPRING and IPPM WG (with the possibility that expertise f= rom the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are c= losely related, I've decided to combine my questions and comments in a sing= le thread. I hope that would be acceptable and considered by the SPRING WG = as well as IPPM WG.

Usually, the bar for the adoption of a document can be evaluated&n= bsp;by answers to these three questions:

  • Is the document(s) reasonably well-written

I've got surprised that the drafts don't use the terminology from = RFC 4656 and 5357 and introduce their own terminology for Session-Sender an= d Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents withou= t proper definitions. Other than that both drafts are readable and reasonab= ly well-written.

<RG> We are ok to change Sender to Se= ssion-Sender and Reflector to Session-Reflector if it helps.

 

GIM>> I believe that the consistency in terminology between the core = RFC and what is intended as its extension is not only helpful to a reader b= ut, to the best of my understanding, is required for IETF specifications. B= ut I don't think that switching the terminology will fix the fundamental issue with the proposal. The operation that is re= quired from the remote entity, whether it is referred to as responder or Se= ssion-Reflector, is not defined in Appendix I of RFC 5357, nor in RFCs 4656= or 5357 itself. In my opinion, the behavior required, as described in the draft, cannot be characterized = as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely n= ew protocol that, if there's a need in the new PM OAM protocol, must be pro= perly defined.

   Gyan> I am in complete agreement with Greg about t= erminology and consistency.  The problem with inconsistency is that th= at you are not following well known normative references required to understand the specification leading to confusion and misunder= standing of the specification.  The goal should be clear and concise i= n terminology and verbiage.

<RG2> Agree. Will address the = terms from RFC 5357 in the next revision.

<RG> There are many existing RFCs tha= t use term =93Link=94 (e.g. RFC 5613, 5340, 8330, etc.) and term =93Congrue= nt Path=94 (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we c= an add a reference for them if it helps.

GIM>> Thank you for listing these RFCs. I think I need to cl= arify my questions. While a reference to any of RFCs you've mentioned, I do= n't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

Now I'll try to illustrate my concern with using the term "co= ngruent path" in these drafts (using ASCII-art):

                  &nb= sp;    C---------D

                  &nb= sp;  /                 \<= o:p>

            A----B    &nbs= p;              E-----F

                  &nb= sp;  \                  /=

                  &nb= sp;  G------------H

Consider an SR tunnel from A to F that traverses the network as A-= B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of "con= gruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and siz= e as the mirror image of the other", it looks as the path A-B-G-H-E-F = is congruent to that SR tunnel. But a packet of an active OAM intended to m= onitor a flow over the SR tunnel is out-of-band relative to that flow and will not produce any meaningful measurement. Of = course, for the case of the extensions in drafts *-twamp-srpm, direct loss = measurement can be performed, as information collected from node F and pack= ets that collect the counters are not required to be in-band with the monitored flow. So, this example, in m= y opinion, illustrates two of my concerns:

=B7 &n= bsp;       using a congruent path for active performance measurement, e.g., TWA= MP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should= reflect the fundamental requirement of ensuring that active OAM test packets are in-band with the monitored fl= ow.

=B7 &n= bsp;       there are no technical requirements to justify using in-band test pa= ckets for direct packet loss measurement. In fact, using the in-band method= for collecting in-profile counters leads to a waste of bandwidth, which ma= y have a negative impact on services that require low-latency and/or low packet loss. As demonstrated in this e= xample, direct packet loss can be performed using an out-of-band mechanism,= e.g., SNMP queries, Netconf notifications based on YANG data model.

  • Does the document solve a real problem?

No, it appears that these drafts define a new performance measurem= ent protocol for the purpose of combining OWAMP and TWAMP functionality and= adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technical ar= guments for using a PM protocol instead of, for example, extending the exis= ting OAM mechanisms like ICMP.

 Gyan>  This may sound basic but is a very critical s= ubject going down the same lines of clarity in verbiage so their is no misu= nderstanding.  =93Congruent=94 by definition means shape of an object and if you super imposed two objects on top of each other the= y fit perfectly and the edges coincide identically.  The problem with = congruent is that it is based on the shape and that shape could be a mirror= image or reflection which may not be exact.  So when referring to a SR-TE path taken this could lead to co= nfusion as to path taken if it=92s the same path or congruent which is vagu= e as to =93exactly=94 which path is taken where here there is criticality a= s to the path being referenced in terms of in-band versus out-of-band.  I agree th= at for direct in band packet loss measurement can be done via existing OAM = mechanisme via ICMP.

<RG2> Ok, we will find an appr= opriate term for =93sending packets on the same path as data traffic=94.

<RG2> Extending ICMP for direc= t-mode loss measurement is outside the scope of this draft. But good to see= the agreement for the direct in band packet loss measurement to be done (albeit by some other means).

GIM2>> I feel that you misunderstand my positi= on in regard to the use case these four documents try to solve. I don't rec= all that I've stated that "direct in-band packet loss measurement"= ; requires any additional standardization work. The Direct Measurement TLV has solved that for STAMP and draft-ietf-ippm-stamp= -option-tlv is now in the RFC Editor's queue. I cannot find any valid techn= ical reason to re-open this and measure the direct packet loss in a slightl= y different way. I must point out that a claim that using fixed positions for the direct packet loss optimiz= es performance does not stand for cases (Section 4.2.1 and 4.2.2 of draft-g= andhi-spring-stamp-srpm) when the return path is specified in the Return Pa= th TLV and, as I understand it, in some cases even the second TLV, Node Address TLV, is used. Thus, it is = clear that the proposed new method of direct packet loss measurement does n= ot offer any significant benefits comparing to the STAMP's Direct Measureme= nt TLV and appears nothing but superfluous.

 

<RG3> The direct= -mode packet loss use-case is typically for the forward direction packet lo= ss. And this does not use the return path TLV. We can clarify that in the d= raft.

<RG> There is a requirement to measur= e performance delay as well as synthetic and direct-mode packet loss in seg= ment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measur= ement today. I am not sure extending ICMP for LM is a good option here.

GIM>> I agree with the requirements you've listed (though the&nb= sp;SPRING WG OAM requirements document has = been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason to use OWAMP/TWAMP for exclusi= ve direct packet loss measurement.  

    Gyan> Agreed

<RG2> There is definitely a need to = do direct-mode loss measurement in IP/SR networks, as RFC 6374 mechanisms a= re for MPLS networks. Note that there was an attempt to extend BFD for dire= ct-mode loss measurement for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03)= .

GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense. The work and discussion of= the proposal continues and the new version will be published soon.

 

<RG3> Ok, so = you do see a need for the extensions for the direct-mode packet loss detect= ion and the authors are actively working on an alternate methods using BFD.   

  • Is the proposed solution technically viable?

There are too many unaddressed aspects, particularly the risk intr= oduced by the protocol on network security, to comprehensively evaluate the= proposed solution.

<RG> About your comment on zer= o checksum, this is described in Security section in RFC 6936. We will add = reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

GIM>> I don't think that a mere reference sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol.

     Gyan> Agreed 0 UDP MIMA security threats an= d that you need to thorough vetting of RFC 6936.

 <RG2> Yes, will add in t= he next revision. Hope we can work together on needed text.

To summarize my review of these two drafts:

  • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

<RG> The probe and response me= ssages defined in [RFC 5357] are used for delay measurement and synthetic p= acket loss. The direct-mode packet loss messages are defined in draf= t-gandhi-ippm-twamp-srpm that matc= h these delay measurement messages. As stated, draft-gandhi-ippm-tw= amp-srpm defines =93extensions=94 = for TWAMP Light.

GIM>> I cannot find where RFC 5357 defines "the probe and respon= se messages". Could you give a more specific reference or provide the = text that, in your opinion, defines such messages? But I'm more concerned w= ith the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to BBF's TR-390, I'm = have learned how different are existing implementations of TWAMP Light. And= that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

  Gyan> I don=92t see the probe a d response messages in T= WAMP RFC 5357 

<RG2> Agree to use term test-p= acket from RFC 5357.

=B7         several parts of the proposed protocol, e.g.= , Zero UDP checksum in IPv6, require detailed security analysis, which is c= urrently absent;

     Gyan> Agreed 

<RG2> Please see previous repl= y.

<RG> This is specified in RFC = 6936 Security Section. We will add reference to this RFC in our Security Se= ction as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

GIM>>  I've noted above that a simple reference does not suffici= ently explains why the use of zero UDP checksum in IPv6 header is not decre= mental, does not create a security risk for the protocol. I believe that th= e proposal to use zero UDP header checksum requires extensive analysis, using the analysis provided in RFC 6936.=

    Gyan> Completely Agree

 <RG2> Please see previou= s reply.

  • I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
<RG> This was to address your previous comment qu=
oted as:
 =93- as I understand, the draft is=
 applicable to TWAMP Light mode,

   mentioned in the informational Appendix I in = RFC 5357, not the TWAMP

   protocol itself. Since TWAMP Light is not a s= tandard but its idea is

   described in the informational text only, I t= hink that the Informational

  track is more appropriate for this specification.= =94

https://m= ailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/

<RG> Having said that, we are = ok to change to PS.

GIM>> As explained in RFC 8545 "TWAMP Light is an idea", no= t a protocol. If anyone is interested in standardizing an "extension&q= uot;, I'd expect that they first define the base specification to which the= extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Could you= point to the definition, for example, of the Authenticated mode in TWAMP L= ight in the draft-gandhi-spring-twamp-srpm or RFC 5357? 

     Gyan> Agreed 

<RG2> The Appendix I of RFC 53= 57 does have information on the Authentication mode. As specified there, th= is is based on user configured parameters.

=B7         I believe that draft-gandhi-spring-twam= p-srpm should be anchored at IPPM WG as it does introduce the new PM protoc= ol.

<RG> The TWAMP Light extension draft-gandhi-ippm-tw= amp-srpm is already in IPPM WG. The SPRING draft only = defines SR PM procedures.

 Below, please find my detailed comments, questions on t= hese drafts:

  • draft-gandhi-spring-twamp-srpm

I have several questions about the relationships between this draf= t and Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light = has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained i= n Section 4 of RFC 8545 (apologies for the long quote):

   "TWAMP Light" is an idea described in Appen= dix I ("TWAMP Light
   (Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
   control protocol combined with the TWAMP-Test protocol.  = In
   [RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
   TWAMP Light failed to meet the requirements for IETF protocols= (there
   are no specifications for negotiating this form of operation a= nd no
   specifications for mandatory-to-implement security features), = as
   described in Appendix A of this memo.  See also [LarsAD] = and
   [TimDISCUSS].

   Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br>    component of TWAMP, it is considered reasonable for future sys= tems to
   use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
   is specified in this document).  Clearly, the TWAMP Light= idea
   envisions many components and communication capabilities beyon= d
   TWAMP-Test (implementing the security requirements, for exampl= e);
   otherwise, Appendix I of [RFC5357] would be one sentence long<= br>    (equating TWAMP Light with TWAMP-Test only).

 Since we don't have an IETF document that addressed these op= en questions, I don't think we can have a draft that proposes extensions to= a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.

 Gyan> Agreed 

<RG2> The procedure for using = the RFC 5357 defined messages in TWAMP Light configuration mode is defined = in the corresponding spring drafts. It also describes the provisioning model.

GIM2>> If a return path can be provisioned for= TWAMP Light, why the same method of controlling a test session cannot be u= sed for STAMP?

 

<RG3> It is not = expected that all STAMP TLV extensions need to be supported for TWAMP Light= using provisioning.

 <RG> This was to address= your previous comment quoted as

 =93- as I understand, the draft is=
 applicable to TWAMP Light mode,

   mentioned in the informational Appendix I in = RFC 5357, not the TWAMP

   protocol itself. Since TWAMP Light is not a s= tandard but its idea is

   described in the informational text only, I t= hink that the Informational

   track is more appropriate for this specificat= ion.=94

https://m= ailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/

<RG> Having said that, we are = ok to change to PS as you mentioned above.

<RG> BTW, despite only differe= nce of fixed vs. variable length payload in STAMP vs. TWAMP Light, the STAM= P is a proposed standard as RFC 8762 (and it uses the same approach of provisioning  as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, = and thus the light, simpler, version of TWAMP-Test component of TWAMP proto= col. I cannot find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of TWAMP Light. Also, I'll prefer not= to refer to RFC 8762 STAMP in the discussion of "extension" to T= WAMP Light.

<RG2> The Authentication infor= mation is user-configured as shown in Section 3.1 of the draft-gandhi-sprin= g-twamp-srpm, and is also described in Appendix I of RFC 5357.

Now a number of more specific questions.

draft-gandhi-spring-twamp-srpm:

  • In the Introduction it is stated that:

  The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provid= es
   simplified mechanisms for active performance measurement in Cu= stomer
   IP networks by provisioning UDP paths and eliminates the need = for
   control-channel signaling.

I can not find where, either Appendix I or TR-390, "elim= inated the need for control-channel signaling". Also, could you point = where the referenced documents describe "provisioning UDP paths"?

<RG> The Appendix I of RFC 5357 has following tex=
t. We can reword and match the exact text if you prefer.<=
/pre>

 


=93This example eliminates the need=
 for the TWAMP-Control protocol, and


   assumes that the Session-Re=
flector is configured=94

GIM>> I think that the text you're proposing is even more co= nfusing. It is not clear which example the sentence is referring to. Also, = what is the basis for such an assumption? 

<RG2> This is the exact text f= rom RFC 5357 Appendix I. Please go through the entire Section in that RFC 5= 357 to avoid =93out of context=94 discussion.

  • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

   The procedure uses the mechanisms defined in [RFC5357= ]
   (TWAMP Light) and its extensions for Performance Measurement.<= o:p>

I think that the reference must be to Appendix I, not RFC 5357. Al= so, could you please specify which extensions of TWAMP Light have been used= in this draft?

<RG> We can add the Appendix I as ref= erence in the next revision. Extensions are defined in draft-gandhi-ippm-tw= amp-srpm, we can add this reference.

GIM>> The problem, in my view, is that Appendix I of RFC 535= 7 must be a normative reference while it is, by its nature, an Informationa= l document.  

<RG2> If approved, it is fine = to have informational draft/RFC in a normative reference. But RFC 5357 is P= S.

  • In Section 2.3 describing the reference model is noted:

    •    The probe response message is typically sent to the s= ender node R1.

    In which scenarios the reflector acts differently? How such behavi= or is related to the behavior of a TWAMP Session-Reflector, as defined in R= FC 5357?

    <RG> Do you prefer we remove =93typic= ally=94 from the sentence?

GIM>> If that fits into the operational model of the new pro= tocol you're defining. 

  • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

<RG> Both, please see Section = 4.1.3. =93Link=94 is well known term used in many existing RFCs (please see= RFC 5613, 5340, 8330).

GIM>> Thank you for the references. I couldn't find a defini= tion of an object "Link" (capitalized) but only "link" = (lower case). Hence, since the draft consistently uses the capitalized form, I consider it to be something else, something different from a link.=  

<RG2> Ok, we can change Link t= o link in the next revision to avoid confusion.

  • In Section 3 behavior of the reflector described as

   ... no PM state for delay or loss measurement need to= be created on the
   reflector node R5.

That is in contradiction to the behavior of a TWAMP Session-Reflec= tor as defined in RFC 5357. Could you provide a reference to an IETF standa= rd where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way= delay and synthetic loss measurement on a bidirectional SR tunnel?

 Gyan> Valid point 

<RG2> Bidirectional SR tunnel = may have an SR state but the statement above is that no PM (i.e. TWAMP Ligh= t) protocol session state is created for it. We can clarify in the next revision.

GIM2>> So-called stateless Session-Reflector i= n TWAMP Light is only one option. I am well-familiar with the implementatio= n that uses the stateful mode. 

 

<RG3> What infor= mation stateful PM need to maintain in the state on the reflector? Doesn=92= t that cause scale issues. We can add in the draft you if there is anything= specifically needed in the spec.

 <RG> Quoting the text fr= om Appendix I in RFC 5357. We can quote the text as is. 

=93In the case of TWAMP Light, the Sessi=
on-Reflector does not necessarily have knowledge of the session state. =93<=
/span>

GIM>> By the informational nature of Appendix I, the text is= not normative. I am familiar with the implementation of TWAMP Light which = does maintain the session state and thus supports one-way packet loss measurement. If you require that the remote node does = not maintain the state, the draft must define that as part of the specifyin= g the behavior of the protocol.

 <RG2> Ok, we can discuss= what information is to be maintained in that state on the reflector for sy= nthetic packet loss. We can add appropriate text if you can help please.

GIM2>> I don't see any reason to do that as th= at already defined in RFC 8762 and draft-ietf-ippm-stamp-yang 

 

<RG3> Ok.=  

=B7         Further, in Section 3 the selection of UDP p= ort explained as the following:

   As specified in [RFC8545], the reflector
   supports the destination UDP port 862 for delay measurement pr= obe
   messages by default.  This UDP port however, is not used = for loss
   measurement probe messages.

To the best of my understanding, as one of the contributors and&nb= sp;Editors of RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Ses= sion-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in th= e same test session, using the same flow of TWAMP-Test packets.<= /p>

 Gyan> Agreed 

<RG2> Yes, we can use port 862= for both delay and synthetic packet loss =96 they are using the same test = packet. There is no change proposed in the draft.

GIM2>> Packet delay and synthetic packet loss = measurements are already supported in RFC 8762. Are you proposing a new pro= tocol to duplicate the STAMP functionalities?

 

<RG3> As mention= ed, the extensions defined are for the direct-mode packet loss measurement = for TWAMP Light and STAMP.

<RG> The packet loss in existi= ng RFC 5357 refers to synthetic loss as there is no support for direct-mode= loss in RFC 5357. We can change the text to clarify as =93This UDP port however, is not used for direct-mode loss meas= urement probe messages.=94

GIM>> I've found that there's some misconception in the draf= t. RFC 8545 re-assigned UDP port 862 not for "delay measurement probe = messages" but for TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, packet loss, reordering (RFC 473= 7 defines packet reordering metric), and packet duplication measurement.

  • Then the draft states that

The sender uses the UDP port number following the guidelines speci= fied in Section 6 in [RFC6335].

Could you point to the guidelines that a user can use when selecti= ng a UDP port number of a test session?

Gyan> Good point  

<RG> Please see section 6 in [RFC6335= ]. We can cite the range which will be the same as used in [RFC8762]. This = was also discussed earlier.

https://mailarchive.ietf.org/arch/msg/i= ppm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

GIM>> I've looked through Section 6 but I don't find anythin= g specifically applicable to this draft we're discussing. If the protocol t= o use UDP port numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it seems that stating that expli= citly would be the best way. 

<RG2> This would be, User Ports and Dynamic Ports=
 ranges, which are defined in [RFC6335=
]. Yes, we can add this text.
  • At the closing of the paragraph, we read that

  The number of UDP ports with PM functionality needs to be m= inimized due
   to limited hardware resources.

Does a UDP port number pose PM functionality? How it is assigned t= o the port number?

<RG> UDP ports are user config= ured for delay and direct-mode loss PM as described in Section 3.1.<= o:p>

GIM>> Can UDP port 862 be used? Also, requiring that the dir= ect-loss measurement uses port number different from the one used by a TWAM= P-Test packet, in my opinion, is another indication that this is the definition of a different from TWAMP Light PM OAM protoco= l. 

<RG2> If we add a field in the= packet then UDP port 862 may be used along with the new field. But it will= require extra processing in hardware. It is better to use a different UDP port for processing efficiency in hardware.<= /span>

  • Following the above-quoted text, in Section 3 is noted:

    •    For Performance Measurement, probe query and response= messages are
       sent as following:

    Could you clarify if the listed further procedures deviate from OW= AMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for Session= -Sender and Session-Reflector respectively?

    <RG> Probe messages follow the same p= rocedure as defined in RFC 4656 and RFC 5357.

GIM>> All messages, i.e., TWAMP-Test packets as well as the = defined in draft-gandhi-ippm-twamp-srpm? 

 <RG2> Yes, unless otherw= ise specified in the draft-gandhi-ippm-twamp-srpm.

  • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

      the probe messages are sent on the
      congruent path of the data traffic by the sender node<= o:p>

It is not clear what "the congruent path" means. The definition o= f congruency in geometry tells us that an object B is congruent t= o object A if it has the same shape and size, but is allowed to flip, slide= or turn. How a path can be congruent to another path?

       Gyan> Agreed.  The use of congr= uent in the context of pathing is confusing as the path being addressed may= not be reflected accurately by the term congruent.

<RG2> As replied above.=

<RG> There are many existing R= FCs that use term Congruent Path (e.g. RFC 5921, 6669) without defining the= m. I suspect it is because it is well-known term. Having said that, we can add a reference for it if it helps reader.<= /span>

GIM>> I cannot assume what was the context of these RFCs. I'= ve sketched a network diagram above to illustrate that a "congrue= nt path" may well lead to out-of-band path. Is that the intention of the authors of the draft to use this protocol out-of-band= ?

<RG2> As replied above.=

  • The last paragraph in Section 3 refers to work on iOAM:

    •    The In-Situ Operations, Administration, and Maintenan= ce (IOAM)
       mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
       SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
       information such as timestamp in-band as part of the data pack= ets,
       and are outside the scope of this document.

    Is iOAM in the scope of this specification? What are the relations= hips between iOAM and draft-gandhi-spring-twamp-srpm?

    <RG> As mentioned in the draft, IOAM = is outside the scope.

GIM>> Yes, but it appears that references to the two IOAM-re= lated drafts have some purpose. What is it? How are these drafts related to=  draft-gandhi-spring-twamp-srpm? 

<RG2> We can remove them if it= is confusing. It is informational text (was added to address a review comm= ent).

  • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?

<RG> Yes, this can be Yang mod= el. We can review draft-ietf-ippm-twamp-yan= g and add any missing items in a s= eparate draft. We can also add a reference in this draft.

GIM>> I think that theremust be some discussion on how = the new protocol is configured. If TWAMP YANG data model can be augmented, = I'd expect that being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything about the configuration of the protocol. = ;

<RG2> The Yang model extension= s are not in the scope of this draft 

  • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

<RG> Existing TWAMP messages d= o not support =93direct-mode=94 loss measurement. We can add =93direct-mode= =94 in the text to clarify.

GIM>> True, direct loss measurement, in fact, is not active = measurement and thus is outside the scope of Two-Way Active Measurement Pro= tocol (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, passive measurement method and fetching= counters can be done using numerous methods, e.g., SNMP, Netconf 

<RG2> RFC 7799 does not say us= ing Test-packets to collect counters for direct-mod loss measurement is pas= sive.

GIM2>> Per RFC 7799, injecting in-band test pa= ckets is the characteristic of an active measurement method. Using out-of-b= and transport, e.g., SNMP queries, would be an example of a passive measure= ment method.

 

<RG3> Ok, so you= answered your own question that the direct-mode packet loss extension defi= ned is =93active measurement=94 method.

  • Section 4.1.1 requires that

  The Destination UDP port cannot be used as Source port, sin= ce
   the message does not have any indication to distinguish betwee= n the
   query and response message.

Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain?

       Gyan> Good question =

<RG2> Yes, it is unique in the= domain.

<RG> This is user-defined and = is up to the user what UDP port to provision in a domain.=

GIM>> So, can user configure a port number from the User Por= ts range? Or, can the same port number be used on the same system for a num= ber of test sessions? I find the use of UDP port numbers being underspecified.

  • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test packet i= n RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet= format to perform both delay and packet loss measurement.

<RG> Ok, we can update the tex= t in the next revision to indicate exact name from the RFC 4656. We can als= o add text to include synthetic packet loss.

GIM>> I think that making it explicit would help. Also, that= will highlight what is being introduced by *twamp-srpm drafts is, in fact,= a new protocol to perform synthetic packet loss measurement. 

 <RG2> No, it does not ch= ange anything for synthetic packet loss.

  • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?

<RG> We can update the text in= the next revision to indicate query format name from RFC 5357.=

GIM>> I cannot find any reference to a query format in RFCs = 4656/5357. Could you please quote from any of these documents?

 <RG2> It is test-packet,= we will use RFC 5357 term.

  • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
<RG> Yes. Please see section 4.1.1 and quoted bel=
ow:
=93For symmetrical size query and respon=
se messages as defined in [RFC6038],=94

GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL= use of the symmetrical test packets. Since *-twamp-srpm proposals do not u= se TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about that either (in part because RFC 6038 came= later), I don't see that there's any certainty in what is the sze of a tes= t packet used in the direct-loss measurement. 

 <RG2> The test-packets a= s defined in these existing RFCs are used for delay and synthetic packet lo= ss. The direct-mode test-packets are defined in this draft.

GIM2>> This draft defines only a new packet fo= rmat for the direct packet loss measurement. For STAMP such a mechanism is = clearly superfluous given the Direct Measurement TLV is already defined.

 

<RG3> As replied= earlier.

  • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

<RG> This is same as TWAMP. Th= ere is no change.

GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the = case for *-twamp-srpm? 

 <RG2> No change in exist= ing in what is there in RFC 5357 and RFC 8186.

  • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

<RG> Hardware timestamps are r= ecommended for SR use-cases. We can change the sentence.<= /p>

GIM>> Perhaps you can propose some text, that would be helpf= ul. 

 <RG2> Ack.

  • Section 4.1.1.1 stated that

   A separate user-configured
   destination UDP port is used for the delay measurement in
   authentication mode due to the different probe message format.=

Can that be interpreted that there could be concurrent authenticat= ed and unauthenticated test sessions using this protocol? Would different a= uthentication methods require using unique destination UDP port numbers?

<RG> Yes, and Yes, and these a= re based on provisioning.

GIM>> But that requirement is far outside the TWAMP, as defi= ned in RFC 5357.

 <RG2> Some Session-Sende= r can use authenticated and some not. It is part of RFC 5357.

  • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

<RG> The direct-mode loss defi= nes new procedure for sender/reflector to collect traffic counters, as oppo= sed to timestamp. The rest is the same as RFC 4656 and 5357.

GIM>> I cannot agree with your statement " The rest is = the same as RFC 4656 and 5357" because the sender's direct-loss format= does not have Error Estimate field, Thus, a reflected packet does not have Sender's Error Estimate, nor Error Estimate of the re= flector. And that, in my opinion, is another clear indication that *twamp-s= rpm drafts define a new protocol, separate from OWAMP/TWAMP.

 <RG2> That field is spec= ific to timestamps and would not apply to counters for direct-mode loss mea= surement.

  • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
  • A couple of question to the following text in Section 4.1.3:

   The local and remote IP
   addresses of the link are used as Source and Destination Addre= sses.
   They can also be IPv6 link local address as probe messages are= pre-
   routed.

    • What are the addresses of a link?

<RG> I am assuming this well-k= nown (e.g. RFC 2328).

GIM>> I am not familiar with the term "pre-routed"= . What does it mean? 

 <RG2> Ensure that packet= s are routed over the link.

    • In which scenarios an IPv6 LLA can be used?

<RG> I am assuming this is wel= l-known (e.g. RFC 5613).

GIM>> So, LLA may be used as the source and destination addr= esses when testing an SR tunnel? 

 <RG2> As mentioned this = is for links.

    • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such a packet will be routed, correct? That does appear as a security threat, would you agree= ?

<RG> Absolutely do not agree. = It is no different than IP routed TWAMP packet as defined in [RFC5357].

GIM>> You don't agree that the processing described cannot h= appen because of laws of physics or it wouldn't happen because no one will = think of that? If the latter, I think that that is security threat.

 <RG2> There is no new th= reat like you have mentioned.

GIM2>> Hmmm, but how the integrity of TLVs pro= posed in draft-gandhi-ippm-stamp-srpm can be protected? These are= not protected by HMAC as presented in figures 3 and 5.   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     

 

<RG3> The extens= ions do not change the processing of these existing TLVs defined for HMAC. = We can add text to indicate this.

  • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the&= nbsp;format of a probe query message. In figure two references to RFC 5357 = are provided - a section that references RFC 4656 OWAMP definition of the S= ession-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the two is= used for the delay measurement in the proposed protocol?

    • <RG> The probe query packet in= the Session-Sender text packet. We can update the name.<= /p>

    • Section 4.2.1 states that

       In one-way measurement mode, the probe response messa= ge as defined in
       Figure 6 is sent back out-of-band to the sender node ...<= /o:p>

    Could you clarify how the responder controls that the response pac= ket is sent not in-band but out-of-band?

    <RG> Please refer to section 3= .1 in draft-gandhi-ippm-twamp-srpm.  This is existing behaviour for ou= t-of-band.

GIM>> draft-gandhi-ippm-twamp-srpm does not specify tha= t it defines another new protocol OWAMP Light. And it is not clear what you= reference as "this is existing behavior". Is it to reference behavior of TWAMP test packet? But the behavior of the TWAMP-= Test protocol by itself is neither in-band, nor out-of-band. It is the enca= psulation of the TWAMP test packet that makes it either in-band or out-of-b= and. 

 <RG2> Right.=

GIM>> So, you believe that proposing to use the method descr= ibed in RFC 8403 for the TWAMP packet is innovation? And what are the benef= its of using the TWAMP test packet format in the Loopback mode?

 <RG2> Please see the dra= ft.

  • What is the rationale for setting TTL/Hop Limit fields always to 255 for IP= v4, MPLS, and IPv6 (per Section 4.3.1)?

<RG> This is as defined in Sec= tion 4.2 of RFC 5357 (Bullet 4).

GIM>> I believe you've misunderstood the text in RFC 5357. T= his bullet specifies the behavior of a Session-Reflector. It is to try to r= ead TTL value of the received TWAMP test packet and copy the value in Sender TTL field of the reflected packet. If the Ses= sion-Reflector cannot access the TTL field, it MUST write 255 in the Sender= TTL field. So, I think that my questions still remains.

 <RG2> Please see Section= 4.2.1 of RFC 5357.

  • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be= lieve that allowing the use of Zero UDP checksum in some scenarios, this pr= otocol introduces a security threat that must be thoroughly analyzed in the= Security Considerations section.

<RG> This is described in RFC = 6936. It will be very specific to the UDP port provisioned for TWAMP. We wi= ll add reference to RFC 6936 in Security Section.

GIM>> I don't think that the reference is sufficient for the= Securit Consideration. I'd expect some extended discussion on why usi= ng zero UDP header checksum is not a security threat for *twamp-srpm  protocol.

 <RG2> Please see reply a= bove.

  • Section 8 refers to "liveness monitoring of Links and SR Paths". = This appears as the replication of functionality provided by BFD/S-BFD prot= ocols. Is such comparison accurate? If it is, shouldn't the proposal be als= o reviewed by the BFD WG?

<RG> TWAMP  probe message= s are used today for synthetic packet loss which can also be used to detect= connection loss (performance metric). The section simply highlights this obvious metric.

GIM>> Can you point to a document that has defined "TWA= MP  probe messages are used today for synthetic packet loss"? Als= o, which document defines loss of connectivity as a performance metric? Does *twamp-srpm proposes to use the new protocol to detect the lo= ss of path continuity?

 <RG2> For example Y.1731= has such notion of connection loss. TWAMP is used widely for synthetic pac= ket loss and is well-known. There is no change in protocol. This is reported metric.

GIM2>> What are packet transmission frequencie= s authors envisioned for that mode? A single-digit millisecond? <= /o:p>

 

<RG3> It depends= on the implementation.

  • I found the Security Section of the proposed protocol inadequately terse an= d missing very important threats that this protocol introduces in the netwo= rk.

<RG> Other than referring RFC = 6936 for zero checksum what else is missing? Otherwise it is no different t= han RFC 8762 (STAMP).

GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm d= rafts. The use of source IP addresses, as mentioned above, appears to be an= other security risk introduced by *-twamp-srpm drafts. 

 <RG2> There is no mentio= n of Source IP address above.

  • draft-gandhi-ippm-twamp-srpm

As I understand it, the motivation for the Loss Measurement mode d= efined in this specification is to collect "in-profile" counters.= Is that correct? Do you see as essential for this mode that the query messages are in-band with the flow being profiled= ? In your opinion, how using an out-of-band method of collecting these coun= ters, e.g., by using ICMP multi-part message extension per RFC 4884, c= ould affect the accuracy comparing with the method in this protocol? How the impact changes if extended ICMP messa= ges are in-band with the profiled flow?

 <RG2> Yes, they need to = be in-band with the flow, to collect the counter from the right forwarding = paths for the flow. Discussion of using ICMP for direct-mode loss measurement is outside the scope of this draft.

GIM2>> I think that the assumption "they = need to be in-band with the flow, to collect the counter from the right for= warding paths for the flow" is technically inaccurate. Otherwise, how = SNMP queries could work for decades of networking history?

 

<RG3> The scope = of this draft is orthogonal to the out of band schemes those may exist.

 

Thanks,

Rakesh

 

<RG> As mentioned earlier, I a= m not sure extending ICMP to do PM is a good option here. Both TWAMP and OW= AMP are widely deployed today for delay and synthetic loss measurement.

GIM>> What is the reason mentioning OWAMP? Are drafts *-twam= p-srpm extend RFC 4656 OWAMP as well? Also, what you see as the connection = between using active measurement methods to measure packet delay and packet loss, on one hand, and collecting packet c= ounters?

 

<RG2> The Session-Sender test-= packet is defined in OWAMP RFC and not TWAMP RFC. Other than timestamp and = its format vs. counter and its format, the messages and processing are the same.

 

Thanks,

Rakesh

 

 

  • Section 3.1 introduces the new field, Sender Control Code. The format of th= e packet, as I understand it, is presented in Figure 1. When comparing with= the format of Session-Sender's test packet defined in RFC 4656 OWAMP in Se= ction 4.1.2 I've noticed that there are no MBZ fields. Are these introduced by your proposal?
    • <= /ul>

    <RG> It shows the partial mess= age that has new field. We can update it to show the full message to avoid = such confusion.

    • Also, it appears that the Sequence Number field in TWAMP Session-Sender's t= est packet is absent in Figure 1. Is that intentional?

    <RG> It shows the partial mess= age that has new field. We can update it to show the full message to avoid = such confusion.

    Thanks,

    Rakesh

     

    Regards,

    Greg

     Thanks 

 

          Gyan 

 

On Thu, Oct 22, 2020 at 5:51 AM James Guichard <james.n.guichard@futur= ewei.com> wrote:

Dear WG:

 

This message starts a 3 week WG adoption call= for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-11 ending Nove= mber 12th 2020. Please note that this document has several changes from v-10 that were requested by the SPR= ING and IPPM chairs. For this reason, the chairs have extended the adoption= call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption.

 

Some background:  

 

Several review comments were received previou= sly for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chairs considered those comments, and upon revie= w of this version of the document, determined the following:

 

 

These conclusions were discussed with the authors of  https://tools.ietf.org/html/draft-gandhi-s= pring-twamp-srpm-10 the result of which is the publication of the following two documents:

 

 

After review of the SPRING document please indicate support (or no= t) for WG adoption to the mailing list. Please also provide comments/reasons for that support = (or lack thereof) as silence will not be considered as consent.=

 

Finally, the chairs would like to thank the a= uthors for their efforts in this matter.

 

Thanks!

 

Jim, Bruno, & Joel

 

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

 

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

--

Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD<= /p>

 

--_000_DM6PR11MB31156BE924B8DF1F37E159BEBFF30DM6PR11MB3115namp_-- From nobody Wed Dec 2 14:18:00 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778BF3A158F; Wed, 2 Dec 2020 14:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SZHvt7Sx66Cp; Wed, 2 Dec 2020 14:17:57 -0800 (PST) Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (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 D98353A157F; Wed, 2 Dec 2020 14:17:56 -0800 (PST) Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa5.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 0B2MHpme012927 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 Dec 2020 22:17:52 GMT Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Wed, 2 Dec 2020 14:17:50 -0800 Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0721.004; Wed, 2 Dec 2020 14:17:50 -0800 From: Michelle Cotton To: "Salz, Rich" , tom petch , "last-call@ietf.org" CC: "acm@research.att.com" , "ippm-chairs@ietf.org" , "draft-ietf-ippm-ioam-data@ietf.org" , "ippm@ietf.org" Thread-Topic: [Ext] Re: [Last-Call] Last Call: (Data Fields for In-situ OAM) to Proposed Standard Thread-Index: AQHWyPj4kr6XazM9qU2Tn8HVMkPmnA== Date: Wed, 2 Dec 2020 22:17:50 +0000 Message-ID: <0E5520CC-D23F-4CF5-8512-E52CF928AEFF@iana.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3689763470_10336077" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-02_13:2020-11-30, 2020-12-02 signatures=0 Archived-At: Subject: Re: [ippm] [Ext] Re: [Last-Call] Last Call: (Data Fields for In-situ OAM) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 22:17:59 -0000 --B_3689763470_10336077 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hello, Comments below, see [MC]. If there is any clarification needed for RFC8126, please let us know so tha= t we can include it in a future revision. --Michelle =EF=BB=BFOn 12/2/20, 7:32 AM, "last-call on behalf of Salz, Rich" wrote: Let me comment on this. I've been one of the three TLS registry experts= for a couple of years. TL;DR I think the draft is not in conflict with how = things are done. On 12/2/20, 5:37 AM, "tom petch" wrote: This I-D seems at odds with RFC8126 over the use of Expert Review i= n s.8.7 ' The responsible AD will appoinht ...' RFC8126 seems clear that the IESG appoints and may do so in advance= and=20 having more than one is recommended Well, the AD is part of the IESG. From what I have seen, registry exper= ts are always appointed by the AD's, as they are expected to be the subject = matter experts. [MC] The Area Director helps identify the expert for a registry, the IESG o= fficially approves/designates the selected person(s). 'the expert will approve or deny..' RFC8126 seems clear that that is the role of IANA. The expert=20 recommends and it is then up to IANA to act IANA's actions are updating the registry. The expert(s) recommendations= are binding. [MC] IANA follows the decisions by the designated experts. IANA facilitate= s any communications and makes the approved updates to the registry. > 'the expert can approve allocations. No, that is the role of IANA; early allocation is possible but that= is=20 the decision of IANA. If there's an expert, IANA will forward to the expert(s) and ask what t= o do. I think reading Section 5 justifies my views above. Perhaps 8126 is no= t internally consistent in some of these details. [MC] Early allocations are decided by the Working Group Chairs and Area Dir= ectors per RFC7120. --=20 last-call mailing list last-call@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-= call__;!!PtGJab4!vb5C1TPMltwSjmb6uQuf0v8FaQPGdMVixEjosDfvFEccssVXgMmoMzVSf_w= Uc3idjfPjm3E-gO0$=20 --B_3689763470_10336077 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIISCwYJKoZIhvcNAQcCoIIR/DCCEfgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg/AMIIFrzCCBJegAwIBAgIQAb9GfdVafWaqP8pChY6LTDANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMjAw ODA3MDAwMDAwWhcNMjIxMDI4MTIwMDAwWjCBzDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxKzApBgNVBAMTIk1pY2hl bGxlIENvdHRvbiAoU01JTUUgMTAvMjgvMjAyMikxJzAlBgkqhkiG9w0BCQEWGG1pY2hlbGxl LmNvdHRvbkBpYW5hLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAORSAuKP yQOZeDT1+C+JyDNFSLkJCkwbQcTKMHyvkFPEXy67Sv9cVLha3EaeURR20z4oolde1w/e2vZI bjXFP1fqmQMcoOOnY5gVwGxNazp+uA0ejyiiibFsp2pNGwmlsH6GS7AhGV6g49fEfxPAJxtJ o07IismVoopRT4nARs4IS/6VNRYi22edeTFEREsLZ3HFYiKSbr7VfB0Vn/JLVK1KGEAVUrIk v5U4WizFYNV63fywq9dBW1DjiS5YbaBvZJ+4jvNr2KLoOHHsliImucd169YblxWw8S6cEJmz uRHI3Mf3NYBePmLb/UEkfJ5p5/BD5yub+i7H4PVu8fmOpOsCAwEAAaOCAfEwggHtMB8GA1Ud IwQYMBaAFOcCI4AAT9jXvJQL2T90OUkyPIp5MB0GA1UdDgQWBBT3VScp2vawiKA5doG9Rn/w tiEaCzAMBgNVHRMBAf8EAjAAMCMGA1UdEQQcMBqBGG1pY2hlbGxlLmNvdHRvbkBpYW5hLm9y ZzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1Ud IAQ8MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2Vy dC5jb20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGln aWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRt MGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNy dDANBgkqhkiG9w0BAQsFAAOCAQEAgLHPW+HEDV2yzgwqbG2RRSVn6gc9Ud82f57MyWDjT3AQ lro1JH641Kz4QWr53rvYQMak1wObyotqJpFTvXD/sGxNypyrVjFcQlYD4lbLO9wymtmmy2VU 2oFbIxiVgLjKOQjMRvyrWqswiQTCQlbHRD+LLHRN2UDRL09rtaiyxokwBlHpicoHerl6CTiq 5oOcq++0hw+5l9QqTLw6Ld+2FN76hu5iXOGpsIR1OnjHgDaNT+xPP4X00c+9gGV8bpr+YLZS P2JFivSZIJicVvB2FE32fAtNYP0Lp7CUX+Asqqq4d75sx9k9ITHtvfdfFWkHeRKYi3d03dAO 5Y99vHOY6zCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNl cnQgU0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 3PgRIz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoF H9pjeFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2 QRdTQDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXq NtdfauIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPh RL16CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQw EgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaG NGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmww OqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD QS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYw ggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQu Y29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQA aABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMA IABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQA IABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIA dAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUA ZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU 5wIjgABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8w DQYJKoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jK wXFRXJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4d OZC+W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5d yBn0UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtn eCweknjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhl s+DibsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUx CzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjEx MTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0 IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0O Fc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+Q rIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlr f9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhV hyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnI sdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0P AQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3z bcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IB AQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVY lzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq 6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBn t2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYICDzCCAgsCAQEw eTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cu ZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAG/ Rn3VWn1mqj/KQoWOi0wwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgyAegaiQ9 HRchXf2tk3jb+fRG+r96NnwKY21D82ECou4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMjAxMjAyMjIxNzQ5WjANBgkqhkiG9w0BAQEFAASCAQB1fv9/baBr PpP3qykB+E2Eaa8I7sq1xeYDSfNSMpLGd6xrKYVf0M3ZnmBmdRBjIubPs9UU5R/UzN4u7FOr 3ZDCpltDnSpnn7BhXzzo5fmgcwNuKNRYIhDmadVZVRf0m+FT1+EywRUyQpoJLP0cL4LHTnRE 2K+HmGibQNvduApTtCWG2gQ1P4tZ6sXKo/ZGLxEnwc6B3Vj5jr9rYArUAAXJ9rJ4448MMm9u YP6NArj6QbdJyqjJlRXOGhMem7u8kIRaPSkLlcjOYMtfftcUCXNOD+togD3WSANiyy9Bhyak m0H9+NMDih1CRyNwtRlD5G7VvRtJidYrZtUgN1ogwPmT --B_3689763470_10336077-- From nobody Wed Dec 2 15:06:25 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12FB3A0762 for ; Wed, 2 Dec 2020 15:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Bt3i-PdHImsL for ; Wed, 2 Dec 2020 15:06:20 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BD83A07C0 for ; Wed, 2 Dec 2020 15:06:20 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id y16so374679ljk.1 for ; Wed, 02 Dec 2020 15:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+L5m6XBOlK5nIxPrnXw0YP3bdwkB7yxSZudWrohpw1c=; b=S+S6Ts2G2nAKF5TbeT7a3q7pFSsD65eSeo60gm2efm/MSuo5+33FXrONFAlqvME5bR 29z/H07tF5z9vA5KLDdT0XE4HJMWQNQnAn6HQVskrRcHlPoB5PfaLLjcSmp/RwB921Hj A2Y9gMutP1FrwsdoJbwQ4dOBe4u/nbjfeOhJvS6s+XRIEN2X/s4pBr3OZfIXcyRuylNl keurmnIudhqW6urUjQTkd/s+v9qKgU+FDbXUqmelY7JoKn3Xf/vGPY5KslSqo8OjScCQ RrNKbO/nRN8N0kFGnIfkJtTNE3TyZRyoI6OqoCUgwvoFi86WYY/aeTc/Du8UW+MT9pdl 7vHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+L5m6XBOlK5nIxPrnXw0YP3bdwkB7yxSZudWrohpw1c=; b=KcT/CLOdgFMO+K3IsH35I1Roq3mOeOjHGGhr1TjHB6oUhMX2k3bDFMQGswYAMwsW+U QxGysnnFu47cVmBj7Er57dVg1EdlslM0hAfDfE7Fs8evhtbWj/P6Y/j5uamwOdt9A8LQ qhV35BoKghFuyd/r3ut91QTzU72uQGkglZPik03JskHZUQRD8lRfZ+2yATcp7EJAphkH BUkBI5bXYr1azuSuorPDHaKIZcyr8SFuZvx4/xhF+i2LKWnrEZsnNrfsI6nPJuRi6jlY 9YXDQ5Uz1Tk51dEnPzF0HXGUG6RdJUmQIz2dxATktAMt7TX9hS0RE6FrlGUi9qVo7lOT 1ebw== X-Gm-Message-State: AOAM533hAkMd25slWrZuTTFEps8oilxNxqJS6bMONBEhLRlzGNyWPxRO XVADxdstIuyaPoxEZhXLwEdpVXiKQCuEMcdvrZ8= X-Google-Smtp-Source: ABdhPJyu2osWsprwm+WSIfWuVPhEHid+Xln2gCxktqLFds4MPZx1T4NtjSGBBBqcnYiAD2D5tJVb7CjQ6UiWyWPFHZg= X-Received: by 2002:a2e:984e:: with SMTP id e14mr84296ljj.110.1606950378071; Wed, 02 Dec 2020 15:06:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Wed, 2 Dec 2020 15:06:07 -0800 Message-ID: To: Martin Duke Cc: IETF IPPM WG , Greg Mirsky Content-Type: multipart/alternative; boundary="00000000000074ec0905b5834a23" Archived-At: Subject: Re: [ippm] Is loopback/direct export amplification worse than linear? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 23:06:24 -0000 --00000000000074ec0905b5834a23 Content-Type: text/plain; charset="UTF-8" Hi Martin, thank you for highlighting some troublesome characteristics of using the Loopback flag in IOAM. I agree that draft-ietf-ippm-ioam-flags could tighten up the description of scenarios when the Loopback flag is used. Also, it seems that the behavior of Direct Export can benefit from more clarifications. Now I've read both drafts taking notes and present them to you below: *draft-ietf-ippm-ioam-flags:* - draft-ietf-ippm-ioam-data defined IOAM as a method to record "operational and telemetry information in the packet while the packet traverses a path between two points in the network". It is an example of a hybrid measurement method, per RFC 7799 classification. The introduction of the Loopback and Active flags clearly makes IOAM into an active method and thus it should be discussed as a protocol that originates test packets, including potential security threats it may be used to create. - If the purpose of the Loopback flag is producing a series of responses from traversed nodes, then it might be much easier to use not a copy of the original packet but a different packet to respond to the sender (similar to CFM's LTM/LTR). That will avoid any risk of reverse-path amplification. - It is not clear what kind of path is expected in "a return path from transit nodes and destination nodes towards the source (encapsulating node) exists"? For example, if IOAM is used in an SFC environment, would Loopback require the use of an SFP to the sender? - It is not clear what establishes "the identity of the [IOAM] encapsulating node". Some examples would be helpful. - There seems to be a disconnect in handling unexpected looped IOAM packet: In the second paragraph Section 4 it is stated: "If an encapsulating node receives a looped back packet that was not originated from the current encapsulating node, the packet is dropped." But in the second from the last paragraph of the same section is noted that: "If there is no match in the Node ID, the packet is processed like a conventional IOAM-encapsulated packet." - The following probably may be expressed using the definitions from the IANA registry: An IOAM trace option that has the loopback bit set MUST have the value '1' in the most significant bit of IOAM-Trace-Type, and '0' in the rest of the bits of IOAM-Trace-Type. like that: An IOAM Trace Option that has the Loopback bit set MUST have the "hop_Lim and node_id in short format" bit set IOAM-Trace-Type, and MUST have all other bits of IOAM-Trace-Type cleared. - What is the value of collecting "hop_Lim and node_id in short format" on the return path of a packet looped back by an intermediate node? As I understand it, only that information can be collected if the Loopback flag is set. Please correct me if that is not the case. - Can you point where it is specified that when using the Loopback "the packet does not have any payload"? Earlier in Section 4 action of an intermediate node is explained: A loopback bit that is set indicates to the transit nodes processing this option that they are to create a copy of the received packet and send the copy back to the source of the packet. One can understand that the looped back packet is a carbon copy of the original packet less the Loopback flag being cleared. And the actions of the encapsulating node are described as: The encapsulating node either generates synthetic packets with an IOAM trace option that has the loopback flag set, or sets the loopack flag in a subset of the in-transit data packets. Which suggests that, at least in the latter case, the packet with the Loopback flag set does have a payload. - One of the essential aspects of defining an active measurement protocol is the specification of the expected rates that test packets be generated for the intended purpose of the protocol. Some protocols provide a mechanism to negotiate that rate either through its control-plane component or as part of bringing the test session to Up state. I couldn't find any discussion of the expected purpose of using the Active flag, nor sufficient information that would help to set reasonable limits on processing packets with the Active flag set. Also, even though the document is on the Standards track, I find normative language in relation to the security impact of Loopback and Active flags being underused. - Applying rate limits throughout the IOAM domain might be cumbersome. I think that stronger security methods must be defined making using the Loopback and Active options more secure. For example, using authentication to ensure the identity of the encapsulating IOAM node that imposed the Loopback or Active option. *draft-ietf-ippm-ioam-direct-export* - Section 3.1 includes very important assumption: The option [DEX] can be read but not modified by transit nodes. That brings the question What protects the DEX option in particular and IOAM-Option-Types in general? - The description of the processing of the DEX option by encapsulating, transit, and decapsulating nodes in an IOAM domain in all cases states "MAY export the requested IOAM data". What are other possible behaviors of nodes processing the DEX option? - In the last paragraph of Section 3.1 stated: A transit IOAM node that does not support the DEX option SHOULD ignore it. What are other allowed behaviors of a node, whether transit or decapsulating? Report an error? Discard the packet with the DEX option? - Though considerations for performance impact at a collector(s) is sensible, it seems that the impact on the node exporting telemetry information triggered by the DEX should also be considered. - Applying rate limits throughout the IOAM domain might be cumbersome. I think that there could be other methods to improve the security of the DEX option. - I can understand that the identity of a collector(s) of exported information can be provisioned via the management or control plane. But I also believe that there must be a discussion of why the Loopback option is not a special case of the DEX option. Regards, Greg On Sun, Nov 15, 2020 at 9:45 PM Martin Duke wrote: > I recognize that the loopback and direct export drafts discuss potential > amplification results, as a path of length N will generate N packets for > each IOAM packet -- a linear relationship. As these are discussed in the > draft with proposed mitigation, in an editorial sense the job is done. > Whether giving people this kind of foot gun is a good idea is a separate > question, but reasonable people can disagree. > > However, if I understand correctly, certain pathological combinations of > IOAM namespaces could result in amplification far worse than linear. > > 1) Loopback loops > Imagine there is an IOAM namespace that covers the path from Hop A to Hop > D. There is a separate namespace entirely contained in A-D, from hop B from > hop C. Both namespaces enable loopback. > A > --------------------------------------------------------D > > B-------------------------------C > > So a user packet is traveling from A to D. There will be (D-A) loopback > packets headed towards A. The (D - C) loopback packets that generated > between C and D will travel through the encapsulating node at C and then > trigger further loopbacks to C. Thus the total number of packets generated > by the single user packet is > (D - A) + (D - C)(C - B) > and obviousy there could be several of these smaller namespaces, or nested > namespaces, that aggravate the amplification further. > > 2) Direct Export > Direct Export potentially has even worse properties. Suppose namespace A, > N_A hops across, direct exports to a node that is reachable across > namespace B. Namespace B, N_B hops across, direct exports to a node > reachable across namespace A. > > Thus a single user packet sent over namespace A will generate N_A packets > that traverse Namespace B. This will, in turn, generate N_A * N_B packets > that traverse namespace A, which in turn triggers N_A ^ 2 * N_B packets, > and so on. > > In fact, if the namespaces direct export with probability exactly,1/N_A > and 1/N_B, the same level of traffic will ping-pong infinitely. Any more > than that, and the traffic will steadily increase to infinity. If the > probability is 1, the growth is exponential. > > **************** > > This analysis, if correct, raises three questions that I can think of: > - Are these corner cases plausible? > - If so, and they occurred, would the namespace administrators necessarily > be aware of each other? If not, I'm concerned that this is unsafe to deploy. > - Do phenomena like this indicate that the design is brittle and putting > in some "considerations" doesn't really mitigate the dangers here? > > Martin > > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --00000000000074ec0905b5834a23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,
thank you for highlighting some troublesome= characteristics of using the Loopback flag in IOAM. I agree that=C2=A0draf= t-ietf-ippm-ioam-flags could tighten up the description of scenarios when t= he Loopback flag is used. Also, it seems that the behavior of=C2=A0Direct Export=C2=A0can benefit from m= ore clarifications. Now I've read both drafts taking notes and present = them to you below:
draft-ietf-ippm-ioam-flags:
<= ul>
  • draft-ietf-ippm-ioam-data defined IOAM as a method to record "o= perational and telemetry information in the packet while the packet travers= es a path between two points in the network". It is an example of a hy= brid measurement method, per RFC 7799 classification. The introduction of t= he Loopback and Active flags clearly makes IOAM into an active method and t= hus it should be discussed as a protocol that originates test packets, incl= uding potential security threats it may be used to create.
  • If t= he purpose of the Loopback flag is producing a series of responses=C2=A0fro= m traversed nodes, then it might be much easier to use not a copy of the or= iginal packet but a different packet to respond to the sender (similar to C= FM's LTM/LTR). That will avoid any risk of reverse-path amplification.<= /li>
  • It is not clear what kind of path is expected in "a return pat= h from transit nodes and destination nodes towards the source (encapsulatin= g node) exists"? For example, if IOAM is used in an SFC environment, w= ould Loopback require the use of an SFP to the sender?
  • It is not cl= ear what establishes "the identity of the [IOAM] encapsulating node&qu= ot;. Some examples would be helpful.
  • There seems to be a disconnect= in handling unexpected looped IOAM packet:
    • In the second paragraph Sect= ion 4 it is stated:
    "If an encapsulating node receives a loo= ped back packet that was not originated from the current encapsulating node= , the packet is dropped."
    But in the second from the last = paragraph of the same section is noted that:
    "If there is no= match in the Node ID, the packet is processed like a conventional IOAM-enc= apsulated packet."
    • The following probably ma= y be expressed using the definitions from the IANA registry:
    =C2=A0 =C2= =A0An IOAM trace option that has the loopback bit set MUST have the
    =C2= =A0 =C2=A0value '1' in the most significant bit of IOAM-Trace-Type,= and '0' in
    =C2=A0 =C2=A0the rest of the bits of IOAM-Trace-Type= .
    like that:
    =C2=A0 =C2=A0An IOAM Trace Option th= at has the Loopback bit set MUST have the
    =C2=A0 =C2=A0"hop_Lim and= node_id in short format" bit set IOAM-Trace-Type, and MUST=C2=A0
    =C2=A0 =C2=A0have all other bits of IOAM-Trace-Type cleared.
    • What is the value of collecting "hop_Lim and nod= e_id in short format" on the return path of a packet looped back by an= intermediate node? As I understand it, only that information can be collec= ted if the Loopback flag is set. Please correct me if that is not the case.=
    • Can you point where it is specified that when using the Loopback &= quot;the packet does not have any payload"? Earlier in Section 4 actio= n of an intermediate node is explained:
    =C2=A0 =C2=A0A loopback bit that= is set indicates to the transit nodes processing
    =C2=A0 =C2=A0this opti= on that they are to create a copy of the received packet and
    =C2=A0 =C2= =A0send the copy back to the source of the packet.
    One can = understand that the looped back packet is a carbon copy of the original pac= ket less the Loopback flag being cleared. And the actions of the encapsulat= ing node are described as:
    =C2=A0 =C2=A0The encapsulating node ei= ther generates synthetic packets with an
    =C2=A0 =C2=A0IOAM trace option = that has the loopback flag set, or sets the loopack
    =C2=A0 =C2=A0flag in= a subset of the in-transit data packets.
    Which suggests th= at, at least in the latter case, the packet with the Loopback flag set does= have a payload.
    • One of the essential aspects of = defining an active measurement protocol is the specification of the expecte= d rates that test packets be generated for the intended purpose of the prot= ocol. Some protocols provide a mechanism to negotiate that rate either thro= ugh its control-plane component or as part of bringing the test session to = Up state. I couldn't find any discussion of the expected purpose of usi= ng the Active flag, nor sufficient information that would help to set reaso= nable limits on processing packets with the Active flag set. Also, even tho= ugh the document is on the Standards track, I find normative language in re= lation to the security impact of Loopback and Active flags being underused.=
    • Applying rate limits throughout the IOAM domain might be cumbersom= e. I think that stronger security methods must be defined making using=C2= =A0the Loopback and Active options more secure. For example, using authenti= cation to ensure the identity of the encapsulating IOAM node that imposed t= he Loopback or Active option.
    draft-ietf-ippm-ioam-direct-e= xport
    • Section 3.1 includes very important assumpt= ion:
    =C2=A0 The option [DEX] can be read but not modified by transit nod= es.
    That brings the question What protects the DEX option i= n particular and IOAM-Option-Types in general?
    • Th= e description of the processing of the DEX option by encapsulating, transit= , and decapsulating nodes in an IOAM domain in all cases states "MAY e= xport the requested IOAM data". What are other possible behaviors of n= odes processing the DEX option?
    • In the last paragraph=C2=A0of Secti= on 3.1 stated:
    =C2=A0 A transit IOAM node that does not support the DEX = option SHOULD ignore it.
    What are other allowed behaviors o= f a node, whether transit or decapsulating? Report=C2=A0an error? Discard t= he packet with the DEX option?
    • Though considerati= ons for=C2=A0performance impact at=C2=A0a collector(s) is sensible, it seem= s that the impact on the node exporting telemetry information triggered by = the DEX should also be considered.
    • Applying rate limits throughout = the IOAM domain might be cumbersome. I think that there could be other meth= ods to improve the security of the DEX option.
    • I can understand tha= t the identity of a collector(s) of exported information can be provisioned= via the management or control plane. But I also believe that there must be= a discussion of why the Loopback option is not a special case of the DEX o= ption.
    Regards,
    Greg

    On Sun, Nov 15, 2020 at 9= :45 PM Martin Duke <martin.h.duke@gmail.com> wrote:
    I recognize that the loop= back and direct export drafts discuss potential amplification results, as a= path of length N will generate N packets for each IOAM packet -- a linear = relationship. As these are discussed in the draft with proposed=C2=A0mitiga= tion, in an editorial sense the job is done. Whether giving people this kin= d of foot gun is a good idea is a separate question, but reasonable people = can disagree.

    However, if I understand correctly, certai= n pathological combinations of IOAM namespaces could=C2=A0result in amplifi= cation far worse=C2=A0than linear.

    1) Loopback loo= ps
    Imagine there is an IOAM namespace that covers the path from H= op A to Hop D. There is a separate namespace entirely contained in A-D, fro= m hop B from hop C. Both namespaces enable loopback.
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0A --------------------------------------------------------D
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0B-------------------------------C

    <= div>So a user packet is traveling from A to D. There will be (D-A) loopback= packets headed towards A. The (D - C) loopback packets that generated betw= een C and D will travel through the encapsulating=C2=A0node at C and then t= rigger further loopbacks to C. Thus the total number of packets generated b= y the single user packet is
    (D - A)=C2=A0+ (D - C)(C - B)
    and obviousy there could be several of these smaller namespaces, or nest= ed namespaces, that aggravate the amplification further.

    2) Direct Export
    Direct Export potentially has even worse = properties. Suppose namespace A, N_A hops across, direct exports to a node = that is reachable across namespace B. Namespace B, N_B hops across, direct = exports to a node reachable across namespace A.

    Th= us a single user packet sent over namespace A will generate N_A packets tha= t traverse Namespace B. This will, in turn, generate N_A * N_B packets that= traverse namespace A, which in turn triggers N_A ^ 2 * N_B packets, and so= on.

    In fact, if the namespaces direct export with= probability exactly,1/N_A and 1/N_B, the same level of traffic will ping-p= ong infinitely. Any more than that, and the traffic will steadily increase = to infinity. If the probability is 1, the growth is exponential.
    =
    ****************

    This analysis, if = correct, raises three questions that I can think of:
    - Are these = corner cases plausible?
    - If so, and they occurred, would the nam= espace administrators necessarily be aware of each other? If not, I'm c= oncerned that this is unsafe to deploy.
    - Do phenomena like this = indicate that the design is brittle and putting in some "consideration= s" doesn't really mitigate the dangers here?

    <= div>Martin




    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --00000000000074ec0905b5834a23-- From nobody Thu Dec 3 02:49:15 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C1B3A0E80; Thu, 3 Dec 2020 02:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 LtKAxV5KduLN; Thu, 3 Dec 2020 02:49:12 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80115.outbound.protection.outlook.com [40.107.8.115]) (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 2AA0B3A0E6E; Thu, 3 Dec 2020 02:49:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K53fTA/SkWAGbj66lnVBMx6sh7em3K4ftHV/HL2vA7UaDGdTN9sF0w+LJh/iIKueSZyMEirKCLCK+ZstQi1tD4fyR8k5Jx7oKfLnt5YtGzNdld/avrUOcvZFLLa17a3aXIqoHMBm9w935ySeD3fbPwBq++aclnplFCIFOSfhcBWolSz9+Zxb+3GL2O/azufH+14GjVb+5+g+slmfE1MifRtiZMZSj8di8WBJ/iFesqpaPsKQDgdPqtpQo55CwQ0CYa7gMQUxDk5pyQF+5hKPs0+MlSB5DfyeBLxhXIuIHeN/MZviGsLXDaR6p3j1sLt4iJ2jwEmNVa7C2jAx181qfg== 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=njChSg1ThXAzVCkapPgJrxePJ98H6vOJ/sawzuFxoAk=; b=A4nAResAur7dCKpSb+GC1/3Y1Ace8VG5zFnz+OjOEfyD45ohDD4iG2UFA1+W5tdEDhok1xOLaD9UZIttFDMpqKe3FCGkVGMr+tS46eEzeYnAWOohc3tE+jGgiRAhYx2Xzxp0eRYyOvX5K/g9XZhAY35Z0uDo4wD2siscjXdeAwr556Q9uviM4Hs57rl/ZPQQIdGj9QN6LiozTuw9CKm2Hxo6bBVjJyFVMtoGc9J6CejZ3qDoGZ2dNr6lH4hOc30nBjdYXw46sJxAJvBuIzErMXhwwqKUdeOrIVOAlyUBbF1v3AMuW4sjD6mycwJQXIJoY2V0YLJiGzL1mn+Dzqh3SA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=njChSg1ThXAzVCkapPgJrxePJ98H6vOJ/sawzuFxoAk=; b=OPNAzXKdwyMiPQF2eJ0in4yN3s5WnUZaUIQpQpik63Cd39u2o3I9PFM5esCkkRVoH+9EQcg6RXErFggObQZj0dPh8/ztssJkWpBUIacLZf+DxOMMSAG2RK1rzVzPIbpQl0JX1w2UdTrNF2v4w2O3X/uKEOLEspYocZIqpCOAHo8= Received: from AM6PR07MB5784.eurprd07.prod.outlook.com (2603:10a6:20b:95::29) by AM5PR0701MB2849.eurprd07.prod.outlook.com (2603:10a6:203:42::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.9; Thu, 3 Dec 2020 10:49:09 +0000 Received: from AM6PR07MB5784.eurprd07.prod.outlook.com ([fe80::15d0:d260:35ea:7c9b]) by AM6PR07MB5784.eurprd07.prod.outlook.com ([fe80::15d0:d260:35ea:7c9b%6]) with mapi id 15.20.3632.016; Thu, 3 Dec 2020 10:49:09 +0000 From: tom petch To: Michelle Cotton , "Salz, Rich" , "last-call@ietf.org" CC: "acm@research.att.com" , "ippm-chairs@ietf.org" , "draft-ietf-ippm-ioam-data@ietf.org" , "ippm@ietf.org" Thread-Topic: [Ext] Re: [Last-Call] Last Call: (Data Fields for In-situ OAM) to Proposed Standard Thread-Index: AQHWyPj4kr6XazM9qU2Tn8HVMkPmnKnlMAhH Date: Thu, 3 Dec 2020 10:49:09 +0000 Message-ID: References: <0E5520CC-D23F-4CF5-8512-E52CF928AEFF@iana.org> In-Reply-To: <0E5520CC-D23F-4CF5-8512-E52CF928AEFF@iana.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iana.org; dkim=none (message not signed) header.d=none;iana.org; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f6004937-487d-4eed-0080-08d89779105a x-ms-traffictypediagnostic: AM5PR0701MB2849: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TQ3LEaDp7LcvSvDKoSnQuruigXeCg9BMyxMi0HvvK4vlwVP/ugNKv0KRrJ6T/RdFwML4jqWC/0c6ru9SjXqlZUSqQ0F5+nni3VddFb6/iItTmivkY+zwBCnI0rubOkfFaGFZVuYZDF9SCT51pylJVTLMSW/MHRhrpWZsMlPVpfqW11qksxBtV9/zLdmYT6oEMMfZ8W3xhkU1jByW/+pc5MwirtIB3NNiI9Cu5RQoxt77V4DqXbpF76k9ttsp1V4ASy4HbxHniuU2dD2N1sI+6iiCW12ejzjFmProBEVZuEe0tipe3p2eRYl9DeHa3tdN19xwcA0l1IxJR2uqhF0hBaG+6YH40zOXM89zGgsF/pT4fmGU6wXRx2vl7I6z0O5U2alDVJXW1bZPSmMRNojuSA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB5784.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(39860400002)(366004)(136003)(346002)(376002)(478600001)(53546011)(83380400001)(4326008)(6506007)(55016002)(9686003)(86362001)(7696005)(71200400001)(8676002)(8936002)(66556008)(66446008)(66946007)(66476007)(26005)(91956017)(76116006)(64756008)(186003)(52536014)(33656002)(966005)(5660300002)(2906002)(316002)(54906003)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?NVBiWWpuMWkzUSsxd0hjYmNlNU5IdS8xTElSWkJ0RU5vMEUyQ2dveC9oZUtV?= =?utf-8?B?QVhLT1lhMk1qODRjRHA3YlB3ZE5NbTBaWnlwWnEzbnRpL3RJOW5ZcmVNaDd2?= =?utf-8?B?emFkZ1pwMkhnQ1UzT3AyeVd5Y0JDa1lOdnZPOXgwbjdSbE9STFVWaE8wOWI4?= =?utf-8?B?dm93Ym1wL1hqOFBJdjdGWUhFMWRrV1o4NGtiaXNaelJOSjlzSURQQTNHMUh4?= =?utf-8?B?L1J5WGxXUlU0ZTRiMUEvNXh3SXAzem9ib3NBMy9qeWZ5cENlUXZoNFFodFB3?= =?utf-8?B?UVNqc1ByVGFlWVB1MTUvTGtXaGw1MkovNlRpV1JiNXRYc0I0VlZPdUxJbDdE?= =?utf-8?B?RW5BVUI2V3Z5RUdNWnNpR09sbUs1elBCYW5oQTJDbk9Id1RiWW9IeXJXSm1a?= =?utf-8?B?bEJvTDNDSjRrZmFmUUdGeFVxZVJLcVE5TlJ4Qk1mSGFReU5WM3ZQV0hvdkNz?= =?utf-8?B?UGhhVkRmUHRZSE9FVXIyYVhodTJha0xWS1VjdFBhc2RXNWxKR1dKZEZvcjVT?= =?utf-8?B?QUFTVmxMQllaUnFjMnFuUTd1bGVKL0FCVlVYS2h0V0YwT2RNRFRxVVZNQ1FY?= =?utf-8?B?b2l1Y1VIaUFYOStrMkFVYnFGN3NGMXUyMlNnS1BxbXJYWCs2YjVqcyt6M0xC?= =?utf-8?B?d2xNRFJWNzJtTk9HcUJkejVmMVVIRllHV2FETnVJd2dZYzlSQU5UY054RCsx?= =?utf-8?B?VHVHdlJLTk1nYzRNd2hnVElxaGhNRWx1YmtibnE5ZDhDekZ3Q0JZbzNHWWJG?= =?utf-8?B?MEJ0ZVEvR3dMMjU4aktHeUJxRm01QlJqM1dVOVd1T1lDRjJ2ZGFvd2ZnRWVk?= =?utf-8?B?NkRkVTF2K3lIY0V4MjRZRWMxTE5MRDZFVEJiNjVLVUU3T0FnQzNFWUs0Vnls?= =?utf-8?B?ZVdqU3pvSWVGWlQrcWpsenhuRktrcnN4NDFpdzBJY1UvMHU0cy9JbHllYjFT?= =?utf-8?B?K0ZpbzFOelhzS2VYRE9EY091UDhtM0Qyd25tN0JnTFVLT3lBQmEzSzM5U1Iv?= =?utf-8?B?WTh2V0dpMnQ3bnVFNlllWFZHVGN4QlU2R0NnTEtsSjFmbG1rNFpKVWd5czZu?= =?utf-8?B?eTA5S1BOcTZBM0VxT203emozaGI5TER6T3EyQ0ZJa21SRWRwa2FLU0ZLTnQ3?= =?utf-8?B?cHFvTE1PL3p3QnFmMC9nWit3bnNobERwU3Y3b045bUVzOW52TnNzd3VjTzRN?= =?utf-8?B?Y3l6UUpOemtwNjcrK1F3QU9wbG96bkYzamkyT243bWRFZFVzM2lSU25tTkpV?= =?utf-8?B?ci9seEt3TmRTSTZURnI4cW1wVW5lTWI1WSsxc0NUU2lHelI5dUVyb2Zobm9C?= =?utf-8?Q?T9FkHgra/1aIQ=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR07MB5784.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f6004937-487d-4eed-0080-08d89779105a X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2020 10:49:09.3036 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ySTvFibMxn4cxLyUX1SnodCi0iOkSH4MZdWdOeogb6St/sN6RYsqyCZyZuQk71q+WtWSGup2QSsyP+/OhKlLVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2849 Archived-At: Subject: Re: [ippm] [Ext] Re: [Last-Call] Last Call: (Data Fields for In-situ OAM) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 10:49:14 -0000 RnJvbTogaXBwbSA8aXBwbS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgTWljaGVsbGUg Q290dG9uIDxtaWNoZWxsZS5jb3R0b25AaWFuYS5vcmc+ClNlbnQ6IDAyIERlY2VtYmVyIDIwMjAg MjI6MTcKCkhlbGxvLAoKQ29tbWVudHMgYmVsb3csIHNlZSBbTUNdLgpJZiB0aGVyZSBpcyBhbnkg Y2xhcmlmaWNhdGlvbiBuZWVkZWQgZm9yIFJGQzgxMjYsIHBsZWFzZSBsZXQgdXMga25vdyBzbyB0 aGF0IHdlIGNhbiBpbmNsdWRlIGl0IGluIGEgZnV0dXJlIHJldmlzaW9uLgoKPHRwPgpNaWNoZWxs ZQoKVGhhbmsgeW91IGZvciB5b3VyIHRob3VnaHRzIGJlbG93OyBJIGFtIGNvbnRlbnQgd2l0aCB5 b3VyIHdvcmRpbmcuCgpJIGRpZCBoYXZlIG9uZSBhZGRpdGlvbmFsIHRob3VnaHQgdGhhdCB0aGlz IEktRCBsYWNrcyBkZXRhaWxzIG9mIHdoYXQgZmllbGRzIHNob3VsZCBiZSBwcmVzZW50IGluIGFu IGVudHJ5IGFuZCwgZm9yIEV4cGVydCBSZXZpZXcsIFJGQzgxMjYgc2F5cyB0aGF0IHRoZXJlIHNo b3VsZCBiZSBhIGZpZWxkIGZvciBjaGFuZ2UgY29udHJvbGxlciB3aGljaCBzb3VuZHMgZ29vZCB0 byBtZQoKVG9tIFBldGNoCgotLU1pY2hlbGxlCgrvu79PbiAxMi8yLzIwLCA3OjMyIEFNLCAibGFz dC1jYWxsIG9uIGJlaGFsZiBvZiBTYWx6LCBSaWNoIiA8bGFzdC1jYWxsLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIHJzYWx6PTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6 CgogICAgTGV0IG1lIGNvbW1lbnQgb24gdGhpcy4gSSd2ZSBiZWVuIG9uZSBvZiB0aGUgdGhyZWUg VExTIHJlZ2lzdHJ5IGV4cGVydHMgZm9yIGEgY291cGxlIG9mIHllYXJzLiBUTDtEUiBJIHRoaW5r IHRoZSBkcmFmdCBpcyBub3QgaW4gY29uZmxpY3Qgd2l0aCBob3cgdGhpbmdzIGFyZSBkb25lLgoK CiAgICBPbiAxMi8yLzIwLCA1OjM3IEFNLCAidG9tIHBldGNoIiA8ZGFlZHVsdXNAYnRjb25uZWN0 LmNvbT4gd3JvdGU6CgogICAgICAgIFRoaXMgSS1EIHNlZW1zIGF0IG9kZHMgd2l0aCBSRkM4MTI2 IG92ZXIgdGhlIHVzZSBvZiBFeHBlcnQgUmV2aWV3IGluIHMuOC43CgogICAgICAgICcgVGhlIHJl c3BvbnNpYmxlIEFEIHdpbGwgYXBwb2luaHQgLi4uJwogICAgICAgIFJGQzgxMjYgc2VlbXMgY2xl YXIgdGhhdCB0aGUgSUVTRyBhcHBvaW50cyBhbmQgbWF5IGRvIHNvIGluIGFkdmFuY2UgYW5kCiAg ICAgICAgaGF2aW5nIG1vcmUgdGhhbiBvbmUgaXMgcmVjb21tZW5kZWQKCiAgICBXZWxsLCB0aGUg QUQgaXMgcGFydCBvZiB0aGUgSUVTRy4gRnJvbSB3aGF0IEkgaGF2ZSBzZWVuLCByZWdpc3RyeSBl eHBlcnRzIGFyZSBhbHdheXMgYXBwb2ludGVkIGJ5IHRoZSBBRCdzLCBhcyB0aGV5IGFyZSBleHBl Y3RlZCB0byBiZSB0aGUgc3ViamVjdCBtYXR0ZXIgZXhwZXJ0cy4KCltNQ10gVGhlIEFyZWEgRGly ZWN0b3IgaGVscHMgaWRlbnRpZnkgdGhlIGV4cGVydCBmb3IgYSByZWdpc3RyeSwgdGhlIElFU0cg b2ZmaWNpYWxseSBhcHByb3Zlcy9kZXNpZ25hdGVzIHRoZSBzZWxlY3RlZCBwZXJzb24ocykuCgog ICAgICAgICd0aGUgZXhwZXJ0IHdpbGwgYXBwcm92ZSBvciBkZW55Li4nCiAgICAgICAgUkZDODEy NiBzZWVtcyBjbGVhciB0aGF0IHRoYXQgaXMgdGhlIHJvbGUgb2YgSUFOQS4gIFRoZSBleHBlcnQK ICAgICAgICByZWNvbW1lbmRzIGFuZCBpdCBpcyB0aGVuIHVwIHRvIElBTkEgdG8gYWN0CgogICAg SUFOQSdzIGFjdGlvbnMgYXJlIHVwZGF0aW5nIHRoZSByZWdpc3RyeS4gVGhlIGV4cGVydChzKSBy ZWNvbW1lbmRhdGlvbnMgYXJlIGJpbmRpbmcuCgpbTUNdIElBTkEgZm9sbG93cyB0aGUgZGVjaXNp b25zIGJ5IHRoZSBkZXNpZ25hdGVkIGV4cGVydHMuICBJQU5BIGZhY2lsaXRhdGVzIGFueSBjb21t dW5pY2F0aW9ucyBhbmQgbWFrZXMgdGhlIGFwcHJvdmVkIHVwZGF0ZXMgdG8gdGhlIHJlZ2lzdHJ5 LgoKICAgID4gICAgJ3RoZSBleHBlcnQgY2FuIGFwcHJvdmUgYWxsb2NhdGlvbnMuCiAgICAgICAg Tm8sIHRoYXQgaXMgdGhlIHJvbGUgb2YgSUFOQTsgZWFybHkgYWxsb2NhdGlvbiBpcyBwb3NzaWJs ZSBidXQgdGhhdCBpcwogICAgICAgIHRoZSBkZWNpc2lvbiBvZiBJQU5BLgoKICAgIElmIHRoZXJl J3MgYW4gZXhwZXJ0LCBJQU5BIHdpbGwgZm9yd2FyZCB0byB0aGUgZXhwZXJ0KHMpIGFuZCBhc2sg d2hhdCB0byBkby4KCiAgICBJIHRoaW5rIHJlYWRpbmcgU2VjdGlvbiA1IGp1c3RpZmllcyBteSB2 aWV3cyBhYm92ZS4gIFBlcmhhcHMgODEyNiBpcyBub3QgaW50ZXJuYWxseSBjb25zaXN0ZW50IGlu IHNvbWUgb2YgdGhlc2UgZGV0YWlscy4KCltNQ10gRWFybHkgYWxsb2NhdGlvbnMgYXJlIGRlY2lk ZWQgYnkgdGhlIFdvcmtpbmcgR3JvdXAgQ2hhaXJzIGFuZCBBcmVhIERpcmVjdG9ycyBwZXIgUkZD NzEyMC4KCiAgICAtLQogICAgbGFzdC1jYWxsIG1haWxpbmcgbGlzdAogICAgbGFzdC1jYWxsQGll dGYub3JnCiAgICBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sYXN0LWNhbGxfXzshIVB0R0phYjQhdmI1QzFUUE1sdHdTam1i NnVRdWYwdjhGYVFQR2RNVml4RWpvc0RmdkZFY2Nzc1ZYZ01tb016VlNmX3dVYzNpZGpmUGptM0Ut Z08wJAo= From nobody Thu Dec 3 09:52:52 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB3F3A0E12; Thu, 3 Dec 2020 09:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 V-UkRHrjViiv; Thu, 3 Dec 2020 09:52:26 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACFB63A0DA1; Thu, 3 Dec 2020 09:51:53 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id j205so3987575lfj.6; Thu, 03 Dec 2020 09:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uzzt1CuZ4Mk7be/YSAo9fCw4dIwEbK3nkfjUIzdP2os=; b=cQZa1iOLGVFBifMllx01GGV8nddCk7v0suXCOkxoYoPsoata5Jl1pmpd48/X7NiTs5 PoK/1yCnAdLoM2yccPu9pkQVJYWoE/A9jaDhWIkfNbZr/FjFte6njZ+oAEBA8pPerAq/ ugkrCu439TJcz54Eu+odCOg0xTfo1IizhX4AHJVvbbw7NZ9DR6TxfwgfML70FDXE3Vvu ssihG/5vJXWzepneOFMj8FNEspK5ODPBqn98GvAxzL1eNFKhVVpen3vGHtkHohqiSRcv QQqJm+7XgWYBE36KfXVjAmxFKWcBLmtru8Y3s7/xX+bvh6ENkWH5jlHm67oOga9VgWB8 OD0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uzzt1CuZ4Mk7be/YSAo9fCw4dIwEbK3nkfjUIzdP2os=; b=AG121jelFnCMhi92kYLee94Mx6TlglI2VOA7wAn/O9yZ6BzCNdqkZlU3lSN/O91KCx jpSGBmcE7erKlPHpCQxj5UAzkQudDAg8r2uzJPX7NQRXe8AtaI36tX2eo4njtGQBS3Gs APRT8UNDCn3z9fFDBVwKKMsBqCpLQhGeJwP8BjUavIHJ61DlK7rbFyUjtyVZElpz1fbe wVqfT7/ut0BtI25yL3HJeYfOBy+QknEG9qr4EtXpZLd0kl9A9KnKrZXvAEDp4ABZlGbF k5reGHVA8fD+RKP2jLNmFZBoate58YM5VMEN516rjCIfbDlU0dobMnqgwT7qvHHjbUul WfMg== X-Gm-Message-State: AOAM531aWHwbAQDGBPPulKQsmFguY66cmjd1fFZRMm64HS7R+1gBSakk MXdaFGSXV5GKVql3YM6HnCjYIfBRVmewpe874v8= X-Google-Smtp-Source: ABdhPJw54/mHyGD1o3YaCXXtLZsgBRUeHbgItQjMA+zJcHv96Ir+GKy30Tqd4zGBFN20yxBTdHwLAwuq4bGcrtj3Rj8= X-Received: by 2002:ac2:5190:: with SMTP id u16mr1800314lfi.56.1607017911550; Thu, 03 Dec 2020 09:51:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Thu, 3 Dec 2020 09:51:39 -0800 Message-ID: To: "Rakesh Gandhi (rgandhi)" Cc: Gyan Mishra , IETF IPPM WG , James Guichard , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Greg Mirsky Content-Type: multipart/alternative; boundary="000000000000c4089305b59303ef" Archived-At: Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 17:52:46 -0000 --000000000000c4089305b59303ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rakesh, thank you for the continued discussion. You can find my follow-up notes in-line below under GIM3>> tag. I felt that one comment is at the root of our different views on what is considered to be a problem that drafts solve. You've said: As mentioned, the extensions defined are for the direct-mode packet loss measurement for TWAMP Light and STAMP. But draft-ietf-ippm-stamp-option-tlv , currently in Submitted to IESG for Publication WG state according to IETF datatracker, includes Section 4.5 Direct Measurement TLV. It is noted in the section: The Direct Measurement TLV enables collection of the number of in- profile packets, i.e., packets that form a specific data flow, that had been transmitted and received by the Session-Sender and Session- Reflector, respectively. The definition of "in-profile packet" is outside the scope of this document and is left to the test operators to determine. Thus I cannot see any technical need for the introduction of yet another way of direct loss measurement in STAMP. As for the case of TWAMP Light, I believe that there's no sufficient evidence that the proposed direct loss-measurement measurement method benefits existing implementations of TWAMP Light. Also, historically, all extensions applicable to TWAMP Light have been introduced through extending TWAMP proper, i.e., extending TWAMP-Control and TWAMP-Test. The way of "extending" TWAMP Light presented in the drafts we are discussing is, in my opinion, in violation of RFC 5357= . More notes can be found below. Regards, Greg On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgandhi) wrote: > Thank you Greg for your further reply and the discussions. > > *Good to know that you do see a need for the extensions for the > direct-mode packet loss detection and the authors are actively working on > an alternate methods using BFD (as you mentioned below).* > GIM3>> As you've recognized, in draft-mirmin-bfd-extended we build an integrated OAM based on the lightweight Fault Management protocol with optional Performance Monitoring, based on RFC 6374. RFC 6374, in turn, provides a rich set of performance measurement methods, including direct loss measurement. Please see replies inline with =E2=80=A6. > > > > > > *From: *Greg Mirsky > *Date: *Monday, November 30, 2020 at 11:30 AM > *To: *Rakesh Gandhi (rgandhi) > *Cc: *Gyan Mishra , IETF IPPM WG , > James Guichard , ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > spring@ietf.org , Greg Mirsky > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh, > > thank you for the continued discussion. I appreciate your responses. I am > still not convinced of the value these documents add. Please find my > follow-up notes in-line below under the GIM2>> tag. > > > > Regards, > > Greg > > > > > > On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Gyan and Greg for your review comments and discussions. Please > see inline replies with =E2=80=A6 > > *From: *Gyan Mishra > *Date: *Wednesday, November 25, 2020 at 12:34 PM > *To: *Greg Mirsky > *Cc: *IETF IPPM WG , James Guichard < > james.n.guichard@futurewei.com>, Rakesh Gandhi (rgandhi) < > rgandhi@cisco.com>, ippm-chairs@ietf.org , > spring-chairs@ietf.org , spring@ietf.org < > spring@ietf.org> > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh > > I have been following this thread and to help progress the discussion I > would like to provide some comments in-line Gyan> > > Thanks > > Gyan > > On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky wrote= : > > Hi Rakesh, > > thank you for the response to my comments. Please find my follow-up notes > in-lined below under the GIM>> tag. > > Regards, > > Greg > > On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the comments. > > Please see replies inline with =E2=80=A6 > > *From: *ippm > *Date: *Friday, November 6, 2020 at 11:18 AM > *To: *James Guichard > *Cc: *spring@ietf.org , ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > IETF IPPM WG > *Subject: *Re: [ippm] [spring] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Dear Chairs of the SPRING and IPPM WGs, Authors, et al., > > I've found myself in the situation when two related drafts are in the WG > APs in the SPRING and IPPM WG (with the possibility that expertise from t= he > third WG, BFD WG, might be desirable to review the "liveness monitoring")= . > Because these drafts are closely related, I've decided to combine my > questions and comments in a single thread. I hope that would be acceptabl= e > and considered by the SPRING WG as well as IPPM WG. > > Usually, the bar for the adoption of a document can be evaluated by > answers to these three questions: > > - Is the document(s) reasonably well-written > > I've got surprised that the drafts don't use the terminology from RFC 465= 6 > and 5357 and introduce their own terminology for Session-Sender and > Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are > used in the documents without proper definitions. Other than that both > drafts are readable and reasonably well-written. > > We are ok to change Sender to Session-Sender and Reflector to > Session-Reflector if it helps. > > > > GIM>> I believe that the consistency in terminology between the core RFC > and what is intended as its extension is not only helpful to a reader but= , > to the best of my understanding, is required for IETF specifications. But= I > don't think that switching the terminology will fix the fundamental issue > with the proposal. The operation that is required from the remote entity, > whether it is referred to as responder or Session-Reflector, is not defin= ed > in Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion= , > the behavior required, as described in the draft, cannot be characterized > as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely > new protocol that, if there's a need in the new PM OAM protocol, must be > properly defined. > > Gyan> I am in complete agreement with Greg about terminology and > consistency. The problem with inconsistency is that that you are not > following well known normative references required to understand the > specification leading to confusion and misunderstanding of the > specification. The goal should be clear and concise in terminology and > verbiage. > > Agree. Will address the terms from RFC 5357 in the next revision. > > There are many existing RFCs that use term =E2=80=9CLink=E2=80=9D (e= .g. RFC 5613, > 5340, 8330, etc.) and term =E2=80=9CCongruent Path=E2=80=9D (e.g. RFC 592= 1, 6669) without > defining them. I suspect it is because these are well-known terms. Having > said that, we can add a reference for them if it helps. > > GIM>> Thank you for listing these RFCs. I think I need to clarify my > questions. While a reference to any of RFCs you've mentioned, I don't thi= nk > that will address my concern. In reviewed documents, "Link" is capitalize= d > while referenced RFCs used the lower case form for the term "link". Can > these be used interchangeably? Do they refer to the same network object? > > Now I'll try to illustrate my concern with using the term "congruent path= " > in these drafts (using ASCII-art): > > C---------D > > / \ > > A----B E-----F > > \ / > > G------------H > > Consider an SR tunnel from A to F that traverses the network as > A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of > "congruent" as "two figures or objects are congruent if they have the sam= e > shape and size, or if one has the same shape and size as the mirror image > of the other", it looks as the path A-B-G-H-E-F is congruent to that SR > tunnel. But a packet of an active OAM intended to monitor a flow over the > SR tunnel is out-of-band relative to that flow and will not produce any > meaningful measurement. Of course, for the case of the extensions in draf= ts > *-twamp-srpm, direct loss measurement can be performed, as information > collected from node F and packets that collect the counters are not > required to be in-band with the monitored flow. So, this example, in my > opinion, illustrates two of my concerns: > > =C2=B7 using a congruent path for active performance measurement, > e.g., TWAMP or TWAMP Light, may produce information that does not reflect > the condition experienced by the monitored flow. It seems that the > terminology should reflect the fundamental requirement of ensuring that > active OAM test packets are in-band with the monitored flow. > > =C2=B7 there are no technical requirements to justify using in-ba= nd > test packets for direct packet loss measurement. In fact, using the in-ba= nd > method for collecting in-profile counters leads to a waste of bandwidth, > which may have a negative impact on services that require low-latency > and/or low packet loss. As demonstrated in this example, direct packet lo= ss > can be performed using an out-of-band mechanism, e.g., SNMP queries, > Netconf notifications based on YANG data model. > > > - Does the document solve a real problem? > > No, it appears that these drafts define a new performance measurement > protocol for the purpose of combining OWAMP and TWAMP functionality and > adding the ability to collect counters of "in-profile" packets. I couldn'= t > find sufficient technical arguments for using a PM protocol instead of, f= or > example, extending the existing OAM mechanisms like ICMP. > > Gyan> This may sound basic but is a very critical subject going down th= e > same lines of clarity in verbiage so their is no misunderstanding. > =E2=80=9CCongruent=E2=80=9D by definition means shape of an object and i= f you super > imposed two objects on top of each other they fit perfectly and the edges > coincide identically. The problem with congruent is that it is based on > the shape and that shape could be a mirror image or reflection which may > not be exact. So when referring to a SR-TE path taken this could lead to > confusion as to path taken if it=E2=80=99s the same path or congruent whi= ch is > vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here ther= e is criticality > as to the path being referenced in terms of in-band versus out-of-band. = I > agree that for direct in band packet loss measurement can be done via > existing OAM mechanisme via ICMP. > > Ok, we will find an appropriate term for =E2=80=9Csending packets o= n the > same path as data traffic=E2=80=9D. > > Extending ICMP for direct-mode loss measurement is outside the scop= e > of this draft. But good to see the agreement for the direct in band packe= t > loss measurement to be done (albeit by some other means). > > GIM2>> I feel that you misunderstand my position in regard to the use cas= e > these four documents try to solve. I don't recall that I've stated that > "direct in-band packet loss measurement" requires any additional > standardization work. The Direct Measurement TLV has solved that for STAM= P > and draft-ietf-ippm-stamp-option-tlv is now in the RFC Editor's queue. I > cannot find any valid technical reason to re-open this and measure the > direct packet loss in a slightly different way. I must point out that a > claim that using fixed positions for the direct packet loss optimizes > performance does not stand for cases (Section 4.2.1 and 4.2.2 of > draft-gandhi-spring-stamp-srpm) when the return path is specified in the > Return Path TLV and, as I understand it, in some cases even the second TL= V, > Node Address TLV, is used. Thus, it is clear that the proposed new method > of direct packet loss measurement does not offer any significant benefits > comparing to the STAMP's Direct Measurement TLV and appears nothing but > superfluous. > > > > The direct-mode packet loss use-case is typically for the forward > direction packet loss. And this does not use the return path TLV. We can > clarify that in the draft. > GIM3>> Clarification would be very helpful as your latest note might be interpreted that the proposed mechanisms are not applicable in the case of a bi-directional SR tunnel. > There is a requirement to measure performance delay as well as > synthetic and direct-mode packet loss in segment-routing networks. OWAMP > and TWAMP protocols are widely deployed for performance delay and synthet= ic > packet loss measurement today. I am not sure extending ICMP for LM is a > good option here. > > GIM>> I agree with the requirements you've listed (though the SPRING WG > OAM requirements document > has > been abandoned and expired 3+ years ago). I believe that there's no > sufficient technical reason to use OWAMP/TWAMP for exclusive direct packe= t > loss measurement. > > Gyan> Agreed > > There is definitely a need to do direct-mode loss measurement in > IP/SR networks, as RFC 6374 mechanisms are for MPLS networks. Note that > there was an attempt to extend BFD for direct-mode loss measurement for > this purpose using RFC 6374 loss measurement message (see > draft-mirmin-bfd-extended-03). > > GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended > in the > past tense. The work and discussion of the proposal continues and the new > version will be published soon. > > > > * Ok, so you do see a need for the extensions for the direct-mode > packet loss detection and the authors are actively working on an alternat= e > methods using BFD. * > > > - Is the proposed solution technically viable? > > There are too many unaddressed aspects, particularly the risk introduced > by the protocol on network security, to comprehensively evaluate the > proposed solution. > > About your comment on zero checksum, this is described in Security > section in RFC 6936. We will add reference to this RFC in our Security > Section as well. This is only specific to the UDP port locally provisione= d > in the domain by the operator for TWAMP. Other than this, I did not find > any other security related issue in your review below. > > GIM>> I don't think that a mere reference sufficiently explains why the > use of zero UDP checksum in IPv6 header is not decremental, does not crea= te > a security risk for the protocol. > > Gyan> Agreed 0 UDP MIMA security threats and that you need to > thorough vetting of RFC 6936. > > Yes, will add in the next revision. Hope we can work together on > needed text. > > To summarize my review of these two drafts: > > - these propose a new protocol, not an update or enhancement of the > TWAMP-like protocol; > > The probe and response messages defined in [RFC 5357] are used for > delay measurement and synthetic packet loss. The direct-mode packet loss > messages are defined in draft-gandhi-ippm-twamp-srpm > that > match these delay measurement messages. As stated, > draft-gandhi-ippm-twamp-srpm > defines > =E2=80=9Cextensions=E2=80=9D for TWAMP Light. > > GIM>> I cannot find where RFC 5357 defines "the probe and response > messages". Could you give a more specific reference or provide the text > that, in your opinion, defines such messages? But I'm more concerned with > the direction of "extending" non-protocol referred to as "TWAMP Light". A= s > a contributor to BBF's TR-390, I'm have learned how different are existin= g > implementations of TWAMP Light. And that is also noted in EANTC > Multi-Vendor Interoperability 2019 white paper > . > The status of TWAMP Light is explained in RFC 8545 and I cannot see that = it > can be used as a foundation of any standard. > > Gyan> I don=E2=80=99t see the probe a d response messages in TWAMP RFC = 5357 > > Agree to use term test-packet from RFC 5357. > > =C2=B7 several parts of the proposed protocol, e.g., Zero UDP che= cksum > in IPv6, require detailed security analysis, which is currently absent; > > Gyan> Agreed > > Please see previous reply. > > This is specified in RFC 6936 Security Section. We will add referenc= e > to this RFC in our Security Section as well. This is only specific to the > UDP port locally provisioned in the domain by the operator for TWAMP. > > GIM>> I've noted above that a simple reference does not sufficiently > explains why the use of zero UDP checksum in IPv6 header is not > decremental, does not create a security risk for the protocol. I believe > that the proposal to use zero UDP header checksum requires extensive > analysis, using the analysis provided in RFC 6936. > > Gyan> Completely Agree > > Please see previous reply. > > > - I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on > the Informational track even though it is essential to the new protoco= l as > it defines its key elements > > This was to address your previous comment quoted as: > > =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Information= al > > track is more appropriate for this specification.=E2=80=9D > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > Having said that, we are ok to change to PS. > > GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. > If anyone is interested in standardizing an "extension", I'd expect that > they first define the base specification to which the extension applies. = I > might have missed the definition of TWAMP Light protocol in the draft. Co= uld > you point to the definition, for example, of the Authenticated mode in > TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? > > Gyan> Agreed > > The Appendix I of RFC 5357 does have information on the > Authentication mode. As specified there, this is based on user configured > parameters. > > =C2=B7 I believe that draft-gandhi-spring-twamp-srpm should be > anchored at IPPM WG as it does introduce the new PM protocol. > > The TWAMP Light extension draft-gandhi-ippm-twamp-srpm > is > already in IPPM WG. The SPRING draft only defines SR PM procedures. > > Below, please find my detailed comments, questions on these drafts: > > - draft-gandhi-spring-twamp-srpm > > I have several questions about the relationships between this draft and > Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light has > been mentioned. The nature of the TWAMP Light and what is required to mak= e > it a standard is well-explained in Section 4 of RFC 8545 > (apologies for the long > quote): > > "TWAMP Light" is an idea described in Appendix I ("TWAMP Light > (Informative)") of [RFC5357]; TWAMP Light includes an unspecified > control protocol combined with the TWAMP-Test protocol. In > [RFC5357], the TWAMP Light idea was relegated to Appendix I because > TWAMP Light failed to meet the requirements for IETF protocols (there > are no specifications for negotiating this form of operation and no > specifications for mandatory-to-implement security features), as > described in Appendix A of this memo. See also [LarsAD] and > [TimDISCUSS]. > > Since the idea of TWAMP Light clearly includes the TWAMP-Test > component of TWAMP, it is considered reasonable for future systems to > use the TWAMP-Test well-known UDP port (whose reallocated assignment > is specified in this document). Clearly, the TWAMP Light idea > envisions many components and communication capabilities beyond > TWAMP-Test (implementing the security requirements, for example); > otherwise, Appendix I of [RFC5357] would be one sentence long > (equating TWAMP Light with TWAMP-Test only). > > Since we don't have an IETF document that addressed these open questions= , > I don't think we can have a draft that proposes extensions to a > non-standard mechanism (Appendix is for Informational material, as I > understand it) on the Standard track. > > Gyan> Agreed > > The procedure for using the RFC 5357 defined messages in TWAMP Ligh= t > configuration mode is defined in the corresponding spring drafts. It also > describes the provisioning model. > > GIM2>> If a return path can be provisioned for TWAMP Light, why the same > method of controlling a test session cannot be used for STAMP? > > > > It is not expected that all STAMP TLV extensions need to be > supported for TWAMP Light using provisioning. > This was to address your previous comment quoted as > > =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Information= al > > track is more appropriate for this specification.=E2=80=9D > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > Having said that, we are ok to change to PS as you mentioned above. > > BTW, despite only difference of fixed vs. variable length payload in > STAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and = it > uses the same approach of provisioning as defined in this draft). Hence, > security considerations for STAMP and TWAMP Light are not different. Note > that both STAMP and TWAMP Light have authenticated messages defined for > Security purpose. > > GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the > light, simpler, version of TWAMP-Test component of TWAMP protocol. I cann= ot > find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mo= de > of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the > discussion of "extension" to TWAMP Light. > > The Authentication information is user-configured as shown in > Section 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described = in > Appendix I of RFC 5357. > > Now a number of more specific questions. > > draft-gandhi-spring-twamp-srpm: > > - In the Introduction it is stated that: > > The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides > simplified mechanisms for active performance measurement in Customer > IP networks by provisioning UDP paths and eliminates the need for > control-channel signaling. > > I can not find where, either Appendix I or TR-390, "eliminated the need > for control-channel signaling". Also, could you point where the reference= d > documents describe "provisioning UDP paths"? > > The Appendix I of RFC 5357 has following text. We can reword and mat= ch the exact text if you prefer. > > > > =E2=80=9CThis example eliminates the need for the TWAMP-Control protocol,= and > > assumes that the Session-Reflector is configured=E2=80=9D > > GIM>> I think that the text you're proposing is even more confusing. It i= s > not clear which example the sentence is referring to. Also, what is the > basis for such an assumption? > > This is the exact text from RFC 5357 Appendix I. Please go through > the entire Section in that RFC 5357 to avoid =E2=80=9Cout of context=E2= =80=9D discussion. > > > - It appears that the last paragraph in the Introduction describes the > relationship with Appendix I of RFC 5357: > > The procedure uses the mechanisms defined in [RFC5357] > (TWAMP Light) and its extensions for Performance Measurement. > > I think that the reference must be to Appendix I, not RFC 5357. Also, > could you please specify which extensions of TWAMP Light have been used i= n > this draft? > > We can add the Appendix I as reference in the next revision. > Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add this > reference. > > GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a > normative reference while it is, by its nature, an Informational document= . > > If approved, it is fine to have informational draft/RFC in a > normative reference. But RFC 5357 is PS. > > > - In Section 2.3 describing the reference model is noted: > > The probe response message is typically sent to the sender node R1. > > In which scenarios the reflector acts differently? How such behavior is > related to the behavior of a TWAMP Session-Reflector, as defined in RFC > 5357? > > Do you prefer we remove =E2=80=9Ctypically=E2=80=9D from the sentenc= e? > > GIM>> If that fits into the operational model of the new protocol you're > defining. > > > - Also in Section 2.3 a Link is mentioned as an element directly > connecting nodes in the presented reference model. Could you clarify w= hat > is a Link? Is it always a physical connection between two systems or a > virtual? > > Both, please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known= term used in > many existing RFCs (please see RFC 5613, 5340, 8330). > > GIM>> Thank you for the references. I couldn't find a definition of an > object "Link" (capitalized) but only "link" (lower case). Hence, since th= e > draft consistently uses the capitalized form, I consider it to be somethi= ng > else, something different from a link. > > Ok, we can change Link to link in the next revision to avoid > confusion. > > > - In Section 3 behavior of the reflector described as > > ... no PM state for delay or loss measurement need to be created on th= e > reflector node R5. > > That is in contradiction to the behavior of a TWAMP Session-Reflector as > defined in RFC 5357. Could you provide a reference to an IETF standard > where this behavior is defined? Also, how, without creating a state at th= e > Session-Reflector, to achieve one-way delay and synthetic loss measuremen= t > on a bidirectional SR tunnel? > > Gyan> Valid point > > Bidirectional SR tunnel may have an SR state but the statement abov= e > is that no PM (i.e. TWAMP Light) protocol session state is created for it= . > We can clarify in the next revision. > > GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one > option. I am well-familiar with the implementation that uses the stateful > mode. > > > > What information stateful PM need to maintain in the state on the > reflector? Doesn=E2=80=99t that cause scale issues. We can add in the dra= ft you if > there is anything specifically needed in the spec. > GIM3>> RFCs 5357 and 8762 are clear about what information must be maintained by a Session-Reflector. The Session-Reflector must have knowledge of the test session state and count reflected test packets. The value of such a counter must be copied in the Sequence Number field of the reflected packet. Thus the method enables the measurement of the one-way packet loss metric. > Quoting the text from Appendix I in RFC 5357. We can quote the text > as is. > > =E2=80=9CIn the case of TWAMP Light, the Session-Reflector does not neces= sarily have knowledge of the session state. =E2=80=9C > > GIM>> By the informational nature of Appendix I, the text is not > normative. I am familiar with the implementation of TWAMP Light which doe= s > maintain the session state and thus supports one-way packet loss > measurement. If you require that the remote node does not maintain the > state, the draft must define that as part of the specifying the behavior = of > the protocol. > > Ok, we can discuss what information is to be maintained in that > state on the reflector for synthetic packet loss. We can add appropriate > text if you can help please. > > GIM2>> I don't see any reason to do that as that already defined in RFC > 8762 and draft-ietf-ippm-stamp-yang > > > > > Ok. > > =C2=B7 Further, in Section 3 the selection of UDP port explained = as > the following: > > As specified in [RFC8545], the reflector > supports the destination UDP port 862 for delay measurement probe > messages by default. This UDP port however, is not used for loss > measurement probe messages. > > To the best of my understanding, as one of the contributors and Editors o= f > RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflect= or > without excluding any type of measurement. Besides, in TWAMP delay and > packet loss are measured in the same test session, using the same flow of > TWAMP-Test packets. > > Gyan> Agreed > > Yes, we can use port 862 for both delay and synthetic packet loss = =E2=80=93 > they are using the same test packet. There is no change proposed in the > draft. > > GIM2>> Packet delay and synthetic packet loss measurements are already > supported in RFC 8762. Are you proposing a new protocol to duplicate the > STAMP functionalities? > > > > As mentioned, the extensions defined are for the direct-mode packet > loss measurement for TWAMP Light and STAMP. > > The packet loss in existing RFC 5357 refers to synthetic loss as > there is no support for direct-mode loss in RFC 5357. We can change the > text to clarify as =E2=80=9CThis UDP port however, is not used for direct= -mode loss > measurement probe messages.=E2=80=9D > > GIM>> I've found that there's some misconception in the draft. RFC 8545 > re-assigned UDP port 862 not for "delay measurement probe messages" but f= or > TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, > packet loss, reordering (RFC 4737 defines packet reordering metric), and > packet duplication measurement. > > > - Then the draft states that > > The sender uses the UDP port number following the guidelines specified in > Section 6 in [RFC6335]. > > Could you point to the guidelines that a user can use when selecting a UD= P > port number of a test session? > > Gyan> Good point > > Please see section 6 in [RFC6335]. We can cite the range which will > be the same as used in [RFC8762]. This was also discussed earlier. > > https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ > > GIM>> I've looked through Section 6 but I don't find anything specificall= y > applicable to this draft we're discussing. If the protocol to use UDP por= t > numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then = it > seems that stating that explicitly would be the best way. > > This would be, User Ports and Dynamic Ports ranges, which are defin= ed in [RFC6335 ]. Yes, we can add this= text. > > > - At the closing of the paragraph, we read that > > The number of UDP ports with PM functionality needs to be minimized due > to limited hardware resources. > > Does a UDP port number pose PM functionality? How it is assigned to the > port number? > > UDP ports are user configured for delay and direct-mode loss PM as > described in Section 3.1. > > GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss > measurement uses port number different from the one used by a TWAMP-Test > packet, in my opinion, is another indication that this is the definition = of > a different from TWAMP Light PM OAM protocol. > > If we add a field in the packet then UDP port 862 may be used along > with the new field. But it will require extra processing in hardware. It = is > better to use a different UDP port for processing efficiency in hardware. > > > - Following the above-quoted text, in Section 3 is noted: > > For Performance Measurement, probe query and response messages are > sent as following: > > Could you clarify if the listed further procedures deviate from > OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for > Session-Sender and Session-Reflector respectively? > > Probe messages follow the same procedure as defined in RFC 4656 and > RFC 5357. > > GIM>> All messages, i.e., TWAMP-Test packets as well as the defined > in draft-gandhi-ippm-twamp-srpm? > > Yes, unless otherwise specified in the > draft-gandhi-ippm-twamp-srpm. > > > - for both delay and loss measurements draft requires test packet be > transmitted on a congruent path: > > the probe messages are sent on the > congruent path of the data traffic by the sender node > > It is not clear what "the congruent path" means. The definition > of congruency in geometry tells us that an object B is congruent to objec= t > A if it has the same shape and size, but is allowed to flip, slide or tur= n. > How a path can be congruent to another path? > > Gyan> Agreed. The use of congruent in the context of pathing is > confusing as the path being addressed may not be reflected accurately by > the term congruent. > > As replied above. > > There are many existing RFCs that use term Congruent Path (e.g. RFC > 5921, 6669) without defining them. I suspect it is because it is well-kno= wn > term. Having said that, we can add a reference for it if it helps reader. > > GIM>> I cannot assume what was the context of these RFCs. I've sketched a > network diagram above to illustrate that a "congruent path" may well lead > to out-of-band path. Is that the intention of the authors of the draft to > use this protocol out-of-band? > > As replied above. > > > - The last paragraph in Section 3 refers to work on iOAM: > > The In-Situ Operations, Administration, and Maintenance (IOAM) > mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for > SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM > information such as timestamp in-band as part of the data packets, > and are outside the scope of this document. > > Is iOAM in the scope of this specification? What are the relationships > between iOAM and draft-gandhi-spring-twamp-srpm? > > As mentioned in the draft, IOAM is outside the scope. > > GIM>> Yes, but it appears that references to the two IOAM-related drafts > have some purpose. What is it? How are these drafts related > to draft-gandhi-spring-twamp-srpm? > > We can remove them if it is confusing. It is informational text (wa= s > added to address a review comment). > > > - Section 3.1 presents an example of the provisioning model but puts > the definition of the provisioning model outside the scope. Is there a= n > accompanying specification that defines the provisioning model that ca= n be > used in multi-vendor deployment? Could that be YANG data model? What i= s the > relationship with draft-ietf-ippm-twamp-yang > ? Would the > TWAMP YANG data model be augmented? > > Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yan= g > and add any > missing items in a separate draft. We can also add a reference in this > draft. > > GIM>> I think that theremust be some discussion on how the new protocol i= s > configured. If TWAMP YANG data model can be augmented, I'd expect that > being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anythi= ng > about the configuration of the protocol. > > The Yang model extensions are not in the scope of this draft > > > - Section 4.1 states that a new message is introduced to perform the > Loss Measurement in this protocol Why the capability of TWAMP to measu= re > the loss in one-way and two-way is not sufficient? > > Existing TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D= loss > measurement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clar= ify. > > GIM>> True, direct loss measurement, in fact, is not active measurement > and thus is outside the scope of Two-Way Active Measurement Protocol > (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, > passive measurement method and fetching counters can be done using numero= us > methods, e.g., SNMP, Netconf > > RFC 7799 does not say using Test-packets to collect counters for > direct-mod loss measurement is passive. > > GIM2>> Per RFC 7799, injecting in-band test packets is the characteristic > of an active measurement method. Using out-of-band transport, e.g., SNMP > queries, would be an example of a passive measurement method. > > > > Ok, so you answered your own question that the direct-mode packet > loss extension defined is =E2=80=9Cactive measurement=E2=80=9D method. > > > - Section 4.1.1 requires that > > The Destination UDP port cannot be used as Source port, since > the message does not have any indication to distinguish between the > query and response message. > > Does that imply that the Destination UDP port used for the Delay > measurement is unique throughout the particular domain? > > Gyan> Good question > > Yes, it is unique in the domain. > > This is user-defined and is up to the user what UDP port to provisio= n > in a domain. > > GIM>> So, can user configure a port number from the User Ports range? Or, > can the same port number be used on the same system for a number of test > sessions? I find the use of UDP port numbers being underspecified. > > > - Section 4.1.2 of RFC 5357 does not define "the delay measurement > message" but refers to the definition of the Session-Sender's test pac= ket > in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test > packet format to perform both delay and packet loss measurement. > > Ok, we can update the text in the next revision to indicate exact > name from the RFC 4656. We can also add text to include synthetic packet > loss. > > GIM>> I think that making it explicit would help. Also, that will > highlight what is being introduced by *twamp-srpm drafts is, in fact, a n= ew > protocol to perform synthetic packet loss measurement. > > No, it does not change anything for synthetic packet loss. > > > - Can you explain how "the DM probe query message contains the payload > format defined in Section 4.2.1 of [RFC5357]" when the referenced sect= ion > of RFC 5357 defines the format of a Session-Reflector's test packet? > > We can update the text in the next revision to indicate query format > name from RFC 5357. > > GIM>> I cannot find any reference to a query format in RFCs 4656/5357. > Could you please quote from any of these documents? > > It is test-packet, we will use RFC 5357 term. > > > - Can clarify the applicability of RFC 6038 and the symmetrical packet > size? Is it required? Can it be non-symmetrical? > > Yes. Please see section 4.1.1 and quoted below: > > =E2=80=9CFor symmetrical size query and response messages as defined in [= RFC6038],=E2=80=9D > > GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the > symmetrical test packets. Since *-twamp-srpm proposals do not use > TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about > that either (in part because RFC 6038 came later), I don't see that there= 's > any certainty in what is the sze of a test packet used in the direct-loss > measurement. > > The test-packets as defined in these existing RFCs are used for > delay and synthetic packet loss. The direct-mode test-packets are defined > in this draft. > > GIM2>> This draft defines only a new packet format for the direct packet > loss measurement. For STAMP such a mechanism is clearly superfluous given > the Direct Measurement TLV is already defined. > > > > As replied earlier. > > > - Can you clarify the use of the timestamp format, NTP or PTPv2? It is > not clear which is the default, mandatory or optional. > > This is same as TWAMP. There is no change. > > GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for > *-twamp-srpm? > > No change in existing in what is there in RFC 5357 and RFC 8186. > > > - Also, is "hardware support in Segment Routing networks" of the PTPv2 > format required, guaranteed, or something else? > > Hardware timestamps are recommended for SR use-cases. We can change > the sentence. > > GIM>> Perhaps you can propose some text, that would be helpful. > > Ack. > > > - Section 4.1.1.1 stated that > > A separate user-configured > destination UDP port is used for the delay measurement in > authentication mode due to the different probe message format. > > Can that be interpreted that there could be concurrent authenticated and > unauthenticated test sessions using this protocol? Would different > authentication methods require using unique destination UDP port numbers? > > Yes, and Yes, and these are based on provisioning. > > GIM>> But that requirement is far outside the TWAMP, as defined in RFC > 5357. > > Some Session-Sender can use authenticated and some not. It is part > of RFC 5357. > > > - Section 4.1.2 by introducing the dedicated Loss measurement packet > format, effectively modifies the behavior defined in RFC 5357 for > Session-Sender and Session-Reflector. But the document does not state = that. > Can you clarify whether this specification changes the behavior of a > Session-Sender and Session-Reflector as defined in RFC 4656 and RFC 53= 57 > respectively for the support of packet loss measurement? > > The direct-mode loss defines new procedure for sender/reflector to > collect traffic counters, as opposed to timestamp. The rest is the same a= s > RFC 4656 and 5357. > > GIM>> I cannot agree with your statement " The rest is the same as RFC > 4656 and 5357" because the sender's direct-loss format does not have Erro= r > Estimate field, Thus, a reflected packet does not have Sender's Error > Estimate, nor Error Estimate of the reflector. And that, in my opinion, i= s > another clear indication that *twamp-srpm drafts define a new protocol, > separate from OWAMP/TWAMP. > > That field is specific to timestamps and would not apply to > counters for direct-mode loss measurement. > > > - And a similar question about the use of the separate UDP port number > for the authenticated of the packet loss measurement. > - A couple of question to the following text in Section 4.1.3: > > The local and remote IP > addresses of the link are used as Source and Destination Addresses. > They can also be IPv6 link local address as probe messages are pre- > routed. > > - What are the addresses of a link? > > I am assuming this well-known (e.g. RFC 2328). > > GIM>> I am not familiar with the term "pre-routed". What does it mean? > > Ensure that packets are routed over the link. > > > - In which scenarios an IPv6 LLA can be used? > > I am assuming this is well-known (e.g. RFC 5613). > > GIM>> So, LLA may be used as the source and destination addresses when > testing an SR tunnel? > > As mentioned this is for links. > > > - Also, could the use of a routable destination IP address be used as > a DDOS attack vector? Consider the scenario when an attacker genera= tes > SR-encapsulated packets with the destination IP address other than = any of > the SR-terminating nodes. Such a packet will be routed, correct? Th= at does > appear as a security threat, would you agree? > > Absolutely do not agree. It is no different than IP routed TWAMP > packet as defined in [RFC5357]. > > GIM>> You don't agree that the processing described cannot happen because > of laws of physics or it wouldn't happen because no one will think of tha= t? > If the latter, I think that that is security threat. > > There is no new threat like you have mentioned. > > GIM2>> Hmmm, but how the integrity of TLVs proposed > in draft-gandhi-ippm-stamp-srpm can be protected? These are not protected > by HMAC as presented in figures 3 and > 5. > > > > > The extensions do not change the processing of these existing TLVs > defined for HMAC. We can add text to indicate this. > > > - Section 4.1.4.2 references Figure 5 that, as I understand it, > displays the format of a probe query message. In figure two references= to > RFC 5357 are provided - a section that references RFC 4656 OWAMP defin= ition > of the Session-Sender test packet, and a section that defines the > Session-Reflector's reflected packet. Which of the two is used for the > delay measurement in the proposed protocol? > > The probe query packet in the Session-Sender text packet. We can > update the name. > > - Section 4.2.1 states that > > In one-way measurement mode, the probe response message as defined in > Figure 6 is sent back out-of-band to the sender node ... > > Could you clarify how the responder controls that the response packet is > sent not in-band but out-of-band? > > Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This i= s > existing behaviour for out-of-band. > > GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines > another new protocol OWAMP Light. And it is not clear what you reference = as > "this is existing behavior". Is it to reference behavior of TWAMP test > packet? But the behavior of the TWAMP-Test protocol by itself is neither > in-band, nor out-of-band. It is the encapsulation of the TWAMP test packe= t > that makes it either in-band or out-of-band. > > Right. > > > - How's the method described in Section 4.2.3 is different from the > method described in RFC 8403 ? > What is distinctly unique about the loopback mode proposed in the sect= ion? > > There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403= . > > GIM>> So, you believe that proposing to use the method described in RFC > 8403 for the TWAMP packet is innovation? And what are the benefits of usi= ng > the TWAMP test packet format in the Loopback mode? > > Please see the draft. > > > - What is the rationale for setting TTL/Hop Limit fields always to 255 > for IPv4, MPLS, and IPv6 (per Section 4.3.1)? > > This is as defined in Section 4.2 of RFC 5357 (Bullet 4). > > GIM>> I believe you've misunderstood the text in RFC 5357. This bullet > specifies the behavior of a Session-Reflector. It is to try to read TTL > value of the received TWAMP test packet and copy the value in Sender TTL > field of the reflected packet. If the Session-Reflector cannot access the > TTL field, it MUST write 255 in the Sender TTL field. So, I think that my > questions still remains. > > Please see Section 4.2.1 of RFC 5357. > > > - Section 4.3.3 states that a zero-value UDP checksum may be used in > some scenarios. RFC 8085 allows that but in very specific cases that a= re > documented in detail in Section 3.4.1. Do you believe that the case of= this > protocol checks all the requirements for allowing the use of Zero UDP > checksum as specified in RFC 8085? Also, I believe that allowing the u= se of > Zero UDP checksum in some scenarios, this protocol introduces a securi= ty > threat that must be thoroughly analyzed in the Security Considerations > section. > > This is described in RFC 6936. It will be very specific to the UDP > port provisioned for TWAMP. We will add reference to RFC 6936 in Security > Section. > > GIM>> I don't think that the reference is sufficient for the > Securit Consideration. I'd expect some extended discussion on why using > zero UDP header checksum is not a security threat for *twamp-srpm protoc= ol. > > Please see reply above. > > > - Section 8 refers to "liveness monitoring of Links and SR Paths". > This appears as the replication of functionality provided by BFD/S-BFD > protocols. Is such comparison accurate? If it is, shouldn't the propos= al be > also reviewed by the BFD WG? > > TWAMP probe messages are used today for synthetic packet loss which > can also be used to detect connection loss (performance metric). The > section simply highlights this obvious metric. > > GIM>> Can you point to a document that has defined "TWAMP probe messages > are used today for synthetic packet loss"? Also, which document defines > loss of connectivity as a performance metric? Does *twamp-srpm proposes t= o > use the new protocol to detect the loss of path continuity? > > For example Y.1731 has such notion of connection loss. TWAMP is > used widely for synthetic packet loss and is well-known. There is no chan= ge > in protocol. This is reported metric. > > GIM2>> What are packet transmission frequencies authors envisioned for > that mode? A single-digit millisecond? > > > > It depends on the implementation. > > > - I found the Security Section of the proposed protocol inadequately > terse and missing very important threats that this protocol introduces= in > the network. > > Other than referring RFC 6936 for zero checksum what else is missing= ? > Otherwise it is no different than RFC 8762 (STAMP). > > GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The us= e > of source IP addresses, as mentioned above, appears to be another securit= y > risk introduced by *-twamp-srpm drafts. > > There is no mention of Source IP address above. > > > - draft-gandhi-ippm-twamp-srpm > > As I understand it, the motivation for the Loss Measurement mode defined > in this specification is to collect "in-profile" counters. Is that correc= t? > Do you see as essential for this mode that the query messages are in-band > with the flow being profiled? In your opinion, how using an out-of-band > method of collecting these counters, e.g., by using ICMP multi-part messa= ge > extension per RFC 4884, could affect the accuracy comparing with the meth= od > in this protocol? How the impact changes if extended ICMP messages are > in-band with the profiled flow? > > Yes, they need to be in-band with the flow, to collect the counter > from the right forwarding paths for the flow. Discussion of using ICMP fo= r > direct-mode loss measurement is outside the scope of this draft. > > GIM2>> I think that the assumption "they need to be in-band with the flow= , > to collect the counter from the right forwarding paths for the flow" is > technically inaccurate. Otherwise, how SNMP queries could work for decade= s > of networking history? > > > > The scope of this draft is orthogonal to the out of band schemes > those may exist. > > > > Thanks, > > Rakesh > > > > As mentioned earlier, I am not sure extending ICMP to do PM is a goo= d > option here. Both TWAMP and OWAMP are widely deployed today for delay and > synthetic loss measurement. > > GIM>> What is the reason mentioning OWAMP? Are drafts *-twamp-srpm extend > RFC 4656 OWAMP as well? Also, what you see as the connection between usin= g > active measurement methods to measure packet delay and packet loss, on on= e > hand, and collecting packet counters? > > > > The Session-Sender test-packet is defined in OWAMP RFC and not TWAM= P > RFC. Other than timestamp and its format vs. counter and its format, the > messages and processing are the same. > > > > Thanks, > > Rakesh > > > > > > > - Section 3.1 introduces the new field, Sender Control Code. The > format of the packet, as I understand it, is presented in Figure 1. Wh= en > comparing with the format of Session-Sender's test packet defined in R= FC > 4656 OWAMP in Section 4.1.2 I've noticed that there are no MBZ fields.= Are > these introduced by your proposal? > > It shows the partial message that has new field. We can update it to > show the full message to avoid such confusion. > > - Also, it appears that the Sequence Number field in TWAMP > Session-Sender's test packet is absent in Figure 1. Is that intentiona= l? > > It shows the partial message that has new field. We can update it to > show the full message to avoid such confusion. > > Thanks, > > Rakesh > > > > Regards, > > Greg > > Thanks > > > > Gyan > > > > On Thu, Oct 22, 2020 at 5:51 AM James Guichard < > james.n.guichard@futurewei.com> wrote: > > Dear WG: > > > > This message starts a 3 week WG adoption call for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending > November 12th 2020. Please note that this document has several changes > from v-10 that were requested by the SPRING and IPPM chairs. For this > reason, the chairs have extended the adoption call for an additional week > to allow the WG enough time to review these changes before deciding on WG > adoption. > > > > Some background: > > > > Several review comments were received previously for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING > and IPPM chairs considered those comments, and upon review of this versio= n > of the document, determined the following: > > > > - The SPRING document should describe only the procedures relevant to > SPRING with pointers to non-SPRING document/s that define any extensio= ns. > Several extensions including* Control Code Field Extension for TWAMP > Light Messages*, *Loss Measurement Query Message Extensions*, and *Los= s > Measurement Response Message Extensions *were included in > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and > should be removed from the SPRING document. > - The TWAMP extensions included in > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should > be described in a new document published in the IPPM WG. > > > > These conclusions were discussed with the authors of > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result > of which is the publication of the following two documents: > > > > - https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The > subject of this WG adoption call. > - https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This > document will be progressed (if determined by the WG) within the IPPM = WG. > > > > After review of the SPRING document please indicate support (or not) for > WG adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as conse= nt. > > > > Finally, the chairs would like to thank the authors for their efforts in > this matter. > > > > Thanks! > > > > Jim, Bruno, & Joel > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-1347 13101 Columbia Pike *Silver Spring, MD > > > > --000000000000c4089305b59303ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Rakesh,
    thank you for the continue= d discussion. You can find my follow-up notes in-line below under GIM3>&= gt; tag. I felt that one comment is at the root of our different views on w= hat is considered to be a problem that drafts solve. You've said:
    =
    <RG3> As mentioned, the extensions defined are for t= he direct-mode packet loss measurement for TWAMP Light and STAMP.
    But draft-ietf-ippm-stamp-option-tlv, currently in= =C2=A0 Submitted to IESG for Publication WG state according to IETF datatra= cker, includes Section 4.5 Direct Measurement TLV. It is noted in the secti= on:
    =C2=A0 =C2=A0The Direct Measurement TLV enables collection of the n= umber of in-
    =C2=A0 =C2=A0profile packets, i.e., packets that form a spe= cific data flow, that
    =C2=A0 =C2=A0had been transmitted and received by = the Session-Sender and Session-
    =C2=A0 =C2=A0Reflector, respectively.=C2= =A0 The definition of "in-profile packet" is
    =C2=A0 =C2=A0outs= ide the scope of this document and is left to the test operators
    =C2=A0 = =C2=A0to determine.
    Thus I cannot see any technical need for the = introduction=C2=A0of yet another way of direct loss measurement in STAMP. A= s for the case of TWAMP Light, I believe that there's no sufficient evi= dence that the proposed direct loss-measurement measurement method benefits= existing implementations of TWAMP Light. Also, historically, all extension= s applicable to TWAMP Light have been introduced through extending TWAMP pr= oper, i.e., extending TWAMP-Control and TWAMP-Test. The way of "extend= ing" TWAMP Light presented in the drafts we are discussing is, in my o= pinion, in violation of RFC 5357.

    More notes can b= e found below.

    Regards,
    Greg


    On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgan= dhi) <rgandhi@cisco.com> wro= te:

    Thank you Greg= for your further reply and the discussions.

    Good to kno= w that you do see a need for the extensions for the direct-mode packet loss= detection and the authors are actively working on an alternate methods usi= ng BFD (as you mentioned below).

    GIM3>> As you've recognized, in draft-mirmin-bfd-extended= =C2=A0we build an integrated OAM based on the lightweight Fault Management = protocol with optional Performance Monitoring, based on RFC 6374. RFC 6374,= in turn, provides a rich set of performance measurement methods, including= direct loss measurement.

    =

    Please see rep= lies inline with <RG3>=E2=80=A6.

    =C2=A0<= u>

    =C2=A0<= u>

    From: Greg Mirsky <gregimirsky@gmail.com= >
    Date: Monday, November 30, 2020 at 11:30 AM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Gyan Mishra <hayabusagsm@gmail.com>, IETF IPPM WG <ippm@ietf.org>, James Guichard &= lt;jame= s.n.guichard@futurewei.com>, ippm-chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs@ietf.org &l= t;spring-chairs= @ietf.org>, spr= ing@ietf.org <s= pring@ietf.org>, Greg Mirsky <g= regory.mirsky@ztetx.com>
    Subject: Re: [spring] [ippm] WG Adoption Call for h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11<= /u>

    Hi Rakesh,

    thank you for the continued discussion. I appreciate= your responses. I am still not convinced of the value these documents add.= Please find my follow-up notes in-line=C2=A0below under the GIM2>> t= ag.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    =C2=A0

    On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

    Thank you Gyan = and Greg for your review comments and discussions. Please see inline replie= s with <RG2>=E2=80=A6

    From: Gyan Mishra <hayabusagsm@gmail.com= >
    Date: Wednesday, November 25, 2020 at 12:34 PM
    To: Greg Mirsky <gregimirsky@gmail.com>
    Cc: IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com&g= t;, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;
    Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11    =

    =C2=A0Hi Rakesh=C2=A0

    I have been following this thread and to help progre= ss the discussion I would like to provide some comments in-line Gyan>=C2= =A0

    Thanks

    Gyan

    On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

    Hi Rakesh,

    thank you for the response to my comments.=C2=A0Plea= se find my follow-up notes in-lined below under the GIM>> tag.=C2=A0<= u>

    Regards,

    Greg

    On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

    Thank you Greg for taking time for tho= roughly reviewing the documents and providing the comments.

    Please see replies inline with <RG&= gt;=E2=80=A6

    From: ippm <ippm-bounces@ietf.org>= ;
    Date: Friday, November 6, 2020 at 11:18 AM
    To: James Guichard <james.n.guichard@futurewei.com>
    Cc: spring@ietf= .org <spring@ie= tf.org>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
    Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11    =

    Dear Chairs of the SPRING and IPPM WGs, Authors, et = al.,

    I've found myself in the situation when two rela= ted drafts are in the WG APs in the SPRING and IPPM WG (with the possibilit= y that expertise from the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are c= losely related, I've decided to combine my questions and comments in a = single thread. I hope that would be acceptable and considered by the SPRING= WG as well as IPPM WG.

    Usually, the bar for the adoption of a document can = be evaluated=C2=A0by answers to these three questions:

    • Is the document(s) reasonably well-written

    I've got surprised that the drafts don't use= the terminology from RFC 4656 and 5357 and introduce their own terminology= for Session-Sender and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents withou= t proper definitions. Other than that both drafts are readable and reasonab= ly well-written.

    <RG> We are ok to change Sender to Session-Sender and Re= flector to Session-Reflector if it helps.

    =C2=A0

    GIM>> I believe that the consistency in terminology between the core = RFC and what is intended as its extension is not only helpful to a reader b= ut, to the best of my understanding, is required for IETF specifications. B= ut I don't think that switching the terminology will fix the fundamental issue with the proposal. The operation that is re= quired from the remote entity, whether it is referred to as responder or Se= ssion-Reflector, is not defined in Appendix I of RFC 5357, nor in RFCs 4656= or 5357 itself. In my opinion, the behavior required, as described in the draft, cannot be characterized = as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely n= ew protocol that, if there's a need in the new PM OAM protocol, must be= properly defined.

    =C2=A0 =C2=A0Gyan> I am in complete agreement wit= h Greg about terminology and consistency.=C2=A0 The problem with inconsiste= ncy is that that you are not following well known normative references required to understand the specification leading to confusion and misunder= standing of the specification.=C2=A0 The goal should be clear and concise i= n terminology and verbiage.

    <RG2> Agr= ee. Will address the terms from RFC 5357 in the next revision.

    <RG> There are many existing RFCs that use term =E2=80= =9CLink=E2=80=9D (e.g. RFC 5613, 5340, 8330, etc.) and term =E2=80=9CCongru= ent Path=E2=80=9D (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we c= an add a reference for them if it helps.

    GIM>> Thank you for listing these RFCs. I thin= k I need to clarify my questions. While a reference to any of RFCs you'= ve mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

    Now I'll try to illustrate my concern with using= the term "congruent path" in these drafts (using ASCII-art):<= /u>

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0\

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A----B=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E-----F

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 /

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0G------------H

    Consider an SR tunnel from A to F that traverses the= network as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definitio= n of "congruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and siz= e as the mirror image of the other", it looks as the path A-B-G-H-E-F = is congruent to that SR tunnel. But a packet of an active OAM intended to m= onitor a flow over the SR tunnel is out-of-band relative to that flow and will not produce any meaningful measurement. Of = course, for the case of the extensions in drafts *-twamp-srpm, direct loss = measurement can be performed, as information collected from node F and pack= ets that collect the counters are not required to be in-band with the monitored flow. So, this example, in m= y opinion, illustrates two of my concerns:

    =C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 using a congruent path for active performance measurement, e.g., TWA= MP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should= reflect the fundamental requirement of ensuring that active OAM test packets are in-band with the monitored fl= ow.

    =C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 there are no technical requirements to justify using in-band test pa= ckets for direct packet loss measurement. In fact, using the in-band method= for collecting in-profile counters leads to a waste of bandwidth, which ma= y have a negative impact on services that require low-latency and/or low packet loss. As demonstrated in this e= xample, direct packet loss can be performed using an out-of-band mechanism,= e.g., SNMP queries, Netconf notifications based on YANG data model.=

    • Does the document solve a real problem?

    No, it appears that these drafts define a new perfor= mance measurement protocol for the purpose of combining OWAMP and TWAMP fun= ctionality and adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technica= l arguments for using a PM protocol instead of, for example, extending the = existing OAM mechanisms like ICMP.

    =C2=A0Gyan> =C2=A0This may sound basic but is a v= ery critical subject going down the same lines of clarity in verbiage so th= eir is no misunderstanding. =C2=A0=E2=80=9CCongruent=E2=80=9D by definition= means shape of an object and if you super imposed two objects on top of each other the= y fit perfectly and the edges coincide identically.=C2=A0 The problem with = congruent is that it is based on the shape and that shape could be a mirror= image or reflection which may not be exact.=C2=A0 So when referring to a SR-TE path taken this could lead to co= nfusion as to path taken if it=E2=80=99s the same path or congruent which i= s vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here ther= e is criticality as to the path being referenced in terms of in-band versus out-of-band.=C2=A0 I agr= ee that for direct in band packet loss measurement can be done via existing= OAM mechanisme via ICMP.

    <RG2> Ok,= we will find an appropriate term for =E2=80=9Csending packets on the same = path as data traffic=E2=80=9D.

    <RG2> Ext= ending ICMP for direct-mode loss measurement is outside the scope of this d= raft. But good to see the agreement for the direct in band packet loss measurement to be done (albeit by some other means).=

    GIM2>> I feel that you misunderstand my positi= on in regard to the use case these four documents try to solve. I don't= recall that I've stated that "direct in-band packet loss measurem= ent" requires any additional standardization work. The Direct Measurement TLV has solved that for STAMP and draft-ietf-ippm-stamp= -option-tlv is now in the RFC Editor's queue. I cannot find any valid t= echnical reason to re-open this and measure the direct packet loss in a sli= ghtly different way. I must point out that a claim that using fixed positions for the direct packet loss optimiz= es performance does not stand for cases (Section 4.2.1 and 4.2.2 of draft-g= andhi-spring-stamp-srpm) when the return path is specified in the Return Pa= th TLV and, as I understand it, in some cases even the second TLV, Node Address TLV, is used. Thus, it is = clear that the proposed new method of direct packet loss measurement does n= ot offer any significant benefits comparing to the STAMP's Direct Measu= rement TLV and appears nothing but superfluous.

    =C2=A0

    <RG3> Th= e direct-mode packet loss use-case is typically for the forward direction p= acket loss. And this does not use the return path TLV. We can clarify that = in the draft.

    GIM= 3>> Clarification would be very helpful as your latest note might be = interpreted that the proposed mechanisms are not applicable in the case of = a bi-directional SR tunnel.
    =

    <RG> There is a requirement to measure performance delay= as well as synthetic and direct-mode packet loss in segment-routing networ= ks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measur= ement today. I am not sure extending ICMP for LM is a good option here.

    GIM>> I agree with the=C2=A0requirements you've listed (though th= e=C2=A0SPRING WG OAM requirements document=C2=A0= has been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason=C2=A0to use OWAMP/TWAMP for exc= lusive direct packet loss measurement.=C2=A0=C2=A0

    =C2=A0 =C2=A0 Gyan> Agreed

    <RG2> There is definitely a n= eed to do direct-mode loss measurement in IP/SR networks, as RFC 6374 mecha= nisms are for MPLS networks. Note that there was an attempt to extend BFD f= or direct-mode loss measurement for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03)= .

    GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense. The work and discussion of= the proposal continues and the new version will be published soon.<= u>

    =C2=A0

    <RG3>= Ok, so you do see a need for the extensions for the direct-mode packet los= s detection and the authors are actively working on an alternate methods us= ing BFD. =C2=A0=C2=A0=

    • Is the proposed solution technically viable?

    There are too many unaddressed aspects, particularly= the risk introduced by the protocol on network security, to comprehensivel= y evaluate the proposed solution.

    <RG> Abou= t your comment on zero checksum, this is described in Security section in R= FC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

    GIM>> I don't think that a mere reference = sufficiently explains why the use of zero UDP checksum in IPv6 header is no= t decremental, does not create a security risk for the protocol.<= /u>

    =C2=A0=C2=A0 =C2=A0 Gyan> Agreed 0 UDP MIMA secur= ity threats and that you need to thorough vetting of RFC 6936.

    =C2=A0<RG2&g= t; Yes, will add in the next revision. Hope we can work together on needed = text.

    To summarize my review of=C2=A0these two drafts:<= /u>

    • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

    <RG> The = probe and response messages defined in [RFC 5357] are used for delay measur= ement and synthetic packet loss. The direct-mode packet loss messages are defined in draft-gandhi-ippm-twamp-srpm that match these delay measurement messages. As stated, draft-gandhi-= ippm-twamp-srpm defines =E2= =80=9Cextensions=E2=80=9D for TWAMP Light.

    GIM>> I cannot find where RFC 5357 defines "the probe and respon= se messages". Could you give a more specific reference or provide the = text that, in your opinion, defines such messages? But I'm more concern= ed with the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to BBF's=C2=A0TR-390, = I'm have learned how different are existing implementations of TWAMP Li= ght. And that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

    =C2=A0 Gyan> I don=E2=80=99t see the probe a d re= sponse messages in TWAMP RFC 5357=C2=A0

    <RG2> Agr= ee to use term test-packet from RFC 5357.

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 several parts of the proposed protocol, e.g., Z= ero UDP checksum in IPv6, require detailed security analysis, which is curr= ently absent;

    =C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

    <RG2> Ple= ase see previous reply.

    <RG> This= is specified in RFC 6936 Security Section. We will add reference to this R= FC in our Security Section as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

    GIM>>=C2=A0 I've noted above that a simple reference does not suf= ficiently explains why the use of zero UDP checksum in IPv6 header is not d= ecremental, does not create a security risk for the protocol. I believe tha= t the proposal to use zero UDP header checksum requires extensive analysis, using the analysis provided in RFC 6936.

    =C2=A0 =C2=A0 Gyan> Completely Agree

    =C2=A0<RG2&g= t; Please see previous reply.

    • I was surprised to find out that=C2=A0draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
    <RG> This was to address your previous comment quoted as=
:
     =
=E2=80=9C- as I understand, the=
 draft is applicable to TWAMP Light mode,

    =C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

    =C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

    =C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

    =C2=A0 track is more appropriate for th= is specification.=E2=80=9D

    https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

    <RG> Havi= ng said that, we are ok to change to PS.

    GIM>> As explained in RFC 8545 "TWAMP Light is an idea", no= t a protocol. If anyone is interested in standardizing an "extension&q= uot;, I'd expect that they first define the base specification to which= the extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Coul= d you point to the definition, for example, of the Authenticated mode in TW= AMP Light in the=C2=A0draft-gandhi-spring-twamp-srpm or RFC 5357?=C2=A0

    =C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

    <RG2> The= Appendix I of RFC 5357 does have information on the Authentication mode. A= s specified there, this is based on user configured parameters.

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 I believe that=C2=A0draft-gandhi-spring-twamp-s= rpm should be anchored at IPPM WG as it does introduce the new PM protocol.=

    <RG> The = TWAMP Light extension draft-gandhi-= ippm-twamp-srpm is already in IPPM WG. The SPRING draf= t only defines SR PM procedures.

    =C2=A0Below, please find my detailed=C2=A0comments, = questions on these drafts:

    • draft-gandhi-spring-twamp-srpm

    I have several questions about the relationships bet= ween this draft and Appendix I in RFC 5357 where the idea of a mode known a= s TWAMP Light has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained i= n Section 4 of=C2=A0RFC 8545=C2=A0(apologies for the long quote):

    =C2=A0 =C2=A0"TWAMP Light" is an idea desc= ribed in Appendix I ("TWAMP Light
    =C2=A0 =C2=A0(Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
    =C2=A0 =C2=A0control protocol combined with the TWAMP-Test protocol.=C2=A0 = In
    =C2=A0 =C2=A0[RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
    =C2=A0 =C2=A0TWAMP Light failed to meet the requirements for IETF protocols= (there
    =C2=A0 =C2=A0are no specifications for negotiating this form of operation a= nd no
    =C2=A0 =C2=A0specifications for mandatory-to-implement security features), = as
    =C2=A0 =C2=A0described in Appendix A of this memo.=C2=A0 See also [LarsAD] = and
    =C2=A0 =C2=A0[TimDISCUSS].

    =C2=A0 =C2=A0Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br> =C2=A0 =C2=A0component of TWAMP, it is considered reasonable for future sys= tems to
    =C2=A0 =C2=A0use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
    =C2=A0 =C2=A0is specified in this document).=C2=A0 Clearly, the TWAMP Light= idea
    =C2=A0 =C2=A0envisions many components and communication capabilities beyon= d
    =C2=A0 =C2=A0TWAMP-Test (implementing the security requirements, for exampl= e);
    =C2=A0 =C2=A0otherwise, Appendix I of [RFC5357] would be one sentence long<= br> =C2=A0 =C2=A0(equating TWAMP Light with TWAMP-Test only).

    =C2=A0Since we don't have an IETF document that = addressed these open questions, I don't think we can have a draft that = proposes extensions to a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.<= u>

    =C2=A0Gyan> Agreed=C2=A0

    <RG2> The= procedure for using the RFC 5357 defined messages in TWAMP Light configura= tion mode is defined in the corresponding spring drafts. It also describes the provisioning model.

    GIM2>> If a return path can be provisioned for= TWAMP Light, why the same method of controlling a test session cannot be u= sed for STAMP?

    =C2=A0

    <RG3> It= is not expected that all STAMP TLV extensions need to be supported for TWA= MP Light using provisioning.=C2=A0

    =

    <= /p>

    =C2=A0<RG>= ; This was to address your previous comment quoted as<= /p> 

     =
=E2=80=9C- as I understand, the=
 draft is applicable to TWAMP Light mode,

    =C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

    =C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

    =C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

    =C2=A0=C2=A0 track is more appropriate = for this specification.=E2=80=9D

    https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

    <RG> Havi= ng said that, we are ok to change to PS as you mentioned above.

    <RG> BTW,= despite only difference of fixed vs. variable length payload in STAMP vs. = TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it uses the same approach of provisioning=C2=A0 as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

    GIM>> RFC 5357 mentioned TWAMP Light as an una= uthenticated, and thus the light, simpler, version of TWAMP-Test component = of TWAMP protocol. I cannot find in=C2=A0draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of TWAMP Light. Also, I'll prefer= not to refer to RFC 8762 STAMP in the discussion of "extension" = to TWAMP Light.

    <RG2> The= Authentication information is user-configured as shown in Section 3.1 of t= he draft-gandhi-spring-twamp-srpm, and is also described in Appendix I of RFC 5357.

    Now a number of more specific questions.

    draft-gandhi-spring-twamp-srpm:

    • In the Introduction it is stated that:

    =C2=A0 The TWAMP Light [Appendix I in RFC5357] [BBF.= TR-390] provides
    =C2=A0 =C2=A0simplified mechanisms for active performance measurement in Cu= stomer
    =C2=A0 =C2=A0IP networks by provisioning UDP paths and eliminates the need = for
    =C2=A0 =C2=A0control-channel signaling.

    I can not=C2=A0find where, either Appendix I or TR-3= 90, "eliminated the need for control-channel signaling". Also, co= uld you point where the referenced documents describe "provisioning UDP paths"?

    <RG> The Appendix I of RFC 5357 has following text. We c=
an reword and match the exact text if you prefer.

    =
=C2=A0
    

    =
=E2=80=9CThis example eliminate=
s the need for the TWAMP-Control protocol, and
    

    =C2=A0=C2=A0 assumes that the Ses=
sion-Reflector is configured=E2=80=9D

    GIM>> I think that the text you're proposi= ng is even more confusing. It is not clear which example the sentence is re= ferring to. Also, what is the basis for such an assumption?=C2=A0=

    <RG2> Thi= s is the exact text from RFC 5357 Appendix I. Please go through the entire = Section in that RFC 5357 to avoid =E2=80=9Cout of context=E2=80=9D discussi= on.

    • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

    =C2=A0 =C2=A0The procedure uses the mechanisms defin= ed in [RFC5357]
    =C2=A0 =C2=A0(TWAMP Light) and its extensions for Performance Measurement.<= u>

    I think that the reference must be to Appendix I, no= t RFC 5357. Also, could you please specify which extensions of TWAMP Light = have been used in this draft?

    <RG> We can add the Appendix I as reference in the next = revision. Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can ad= d this reference.

    GIM>> The problem, in my view, is that Appendi= x I of RFC 5357 must be a normative reference while it is, by its nature, a= n Informational document.=C2=A0=C2=A0

    <RG2> If = approved, it is fine to have informational draft/RFC in a normative referen= ce. But RFC 5357 is PS.

    • In Section 2.3 describing the reference model is noted:
      • <= /ul>

      =C2=A0 =C2=A0The probe response message is typically= sent to the sender node R1.

      In which scenarios the reflector acts differently? H= ow such behavior is related to the behavior of a TWAMP Session-Reflector, a= s defined in RFC 5357?

      <RG> Do you prefer we remove =E2=80=9Ctypically=E2=80=9D= from the sentence?

    GIM>> If that fits into the operational model = of the new protocol you're defining.=C2=A0

    • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

    <RG> Both= , please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known term used = in many existing RFCs (please see RFC 5613, 5340, 8330).

    GIM>> Thank you for the references. I couldn&#= 39;t find a definition of an object "Link" (capitalized) but only= "link" (lower case). Hence, since the draft consistently uses th= e capitalized form, I consider it to be something else, something different from a link.= =C2=A0

    <RG2> Ok,= we can change Link to link in the next revision to avoid confusion.=

    • In Section 3 behavior of the reflector described as

    =C2=A0 =C2=A0... no PM state for delay or loss measu= rement need to be created on the
    =C2=A0 =C2=A0reflector node R5.

    That is in contradiction to the behavior of a TWAMP = Session-Reflector as defined in RFC 5357. Could you provide a reference to = an IETF standard where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way= delay and synthetic loss measurement on a bidirectional SR tunnel?<= u>

    =C2=A0Gyan> Valid point=C2=A0

    <RG2> Bid= irectional SR tunnel may have an SR state but the statement above is that n= o PM (i.e. TWAMP Light) protocol session state is created for it. We can clarify in the next revision.

    GIM2>> So-called stateless Session-Reflector i= n TWAMP Light is only one option. I am well-familiar with the implementatio= n that uses the stateful mode.=C2=A0

    =C2=A0

    <RG3> Wh= at information stateful PM need to maintain in the state on the reflector? = Doesn=E2=80=99t that cause scale issues. We can add in the draft you if the= re is anything specifically needed in the spec.

    GIM3>> RFCs 5357 and 8762 are clear ab= out what information must be maintained by a Session-Reflector. The Session= -Reflector must have knowledge of the test session state and count reflecte= d test packets. The value of such a counter must be copied in the Sequence = Number field of the reflected packet. Thus=C2=A0the method enables the meas= urement of the one-way packet loss metric.

    =C2=A0<RG>= ; Quoting the text from Appendix I in RFC 5357. We can quote the text as is= .

    =E2=80=9CIn the case of TWAMP Lig=
ht, the Session-Reflector does not necessarily have knowledge of the sessio=
n state. =E2=80=9C

    GIM>> By the informational nature of Appendix = I, the text is not normative. I am familiar with the implementation of TWAM= P Light which does maintain the session state and thus supports one-way packet loss measurement. If you require that the remote node does = not maintain the state, the draft must define that as part of the specifyin= g the behavior of the protocol.

    =C2=A0<RG2&g= t; Ok, we can discuss what information is to be maintained in that state on= the reflector for synthetic packet loss. We can add appropriate text if you can help please.

    GIM2>> I don't see any reason to do that a= s that already defined in RFC 8762 and draft-ietf-ippm-stamp-yang=C2=A0

    =C2=A0

    <RG3> Ok= .=C2=A0

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Further, in Section 3 the selection of UDP port= explained as the following:

    =C2=A0 =C2=A0As specified in [RFC8545], the reflecto= r
    =C2=A0 =C2=A0supports the destination UDP port 862 for delay measurement pr= obe
    =C2=A0 =C2=A0messages by default.=C2=A0 This UDP port however, is not used = for loss
    =C2=A0 =C2=A0measurement probe messages.

    To the best of my understanding, as one of the contr= ibutors and=C2=A0Editors of RFC 8545, it re-allocated UDP port 862 for use = by a TWAMP Session-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in th= e same test session, using the same flow of TWAMP-Test packets.

    =C2=A0Gyan> Agreed=C2=A0

    <RG2> Yes= , we can use port 862 for both delay and synthetic packet loss =E2=80=93 th= ey are using the same test packet. There is no change proposed in the draft= .

    GIM2>> Packet delay and synthetic packet loss = measurements are already supported in RFC 8762. Are you proposing a new pro= tocol to duplicate the STAMP functionalities?

    =C2=A0

    <RG3> As= mentioned, the extensions defined are for the direct-mode packet loss meas= urement for TWAMP Light and STAMP.

    <RG> The = packet loss in existing RFC 5357 refers to synthetic loss as there is no su= pport for direct-mode loss in RFC 5357. We can change the text to clarify as =E2=80=9CThis UDP port however, is not used for direct-mode los= s measurement probe messages.=E2=80=9D

    GIM>> I've found that there's some mis= conception in the draft. RFC 8545 re-assigned UDP port 862 not for "de= lay measurement probe messages" but for TWAMP-Test protocol. TWAMP-Tes= t protocol, in turn, supports packet delay, packet loss, reordering (RFC 473= 7 defines packet reordering metric), and packet duplication measurement.=

    • Then the draft states that

    The sender uses the UDP port number following the gu= idelines specified in Section 6 in [RFC6335].

    Could you point to the guidelines that a user can us= e when selecting a UDP port number of a test session?

    Gyan> Good point =C2=A0

    <RG> Please see section 6 in [RFC6335]. We can cite the = range which will be the same as used in [RFC8762]. This was also discussed = earlier.

    https://mailarchive.ietf.= org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

    GIM>> I've looked through Section 6 but I = don't find anything specifically applicable to this draft we're dis= cussing. If the protocol to use UDP port numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it seems that stating that expli= citly would be the best way.=C2=A0

    <RG2> This would be, User Ports and Dynamic Ports ranges=
, which are defined in [RFC6335=
]. Yes, we can add this text.
    • At the closing of the paragraph, we read that

    =C2=A0 The number of UDP ports with PM functionality= needs to be minimized due
    =C2=A0 =C2=A0to limited hardware resources.

    Does a UDP port number pose PM functionality? How it= is assigned to the port number?

    <RG> UDP = ports are user configured for delay and direct-mode loss PM as described in= Section 3.1.

    GIM>> Can UDP port 862 be used? Also, requirin= g that the direct-loss measurement uses port number different from the one = used by a TWAMP-Test packet, in my opinion, is another indication that this is the definition of a different from TWAMP Light PM OAM protoco= l.=C2=A0

    <RG2> If = we add a field in the packet then UDP port 862 may be used along with the n= ew field. But it will require extra processing in hardware. It is better to use a different UDP port for processing efficiency in hardware.<= /span>

    • Following the above-quoted text, in Section 3 is noted:
      • <= /ul>

      =C2=A0 =C2=A0For Performance Measurement, probe quer= y and response messages are
      =C2=A0 =C2=A0sent as following:

      Could you clarify if the listed further procedures d= eviate from OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 53= 57 for Session-Sender and Session-Reflector respectively?

      <RG> Probe messages follow the same procedure as defined= in RFC 4656 and RFC 5357.

    GIM>> All messages, i.e., TWAMP-Test packets a= s well as the defined in=C2=A0draft-gandhi-ippm-twamp-srpm?=C2=A0=

    =C2=A0<RG2&g= t; Yes, unless otherwise specified in the draft-gandhi-ippm-twamp-srpm.

    • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

    =C2=A0 =C2=A0 =C2=A0 the probe messages are sent on = the
    =C2=A0 =C2=A0 =C2=A0 congruent path of the data traffic by the sender node<= u>

    It is not clear what "the congruent path" means. The definition o= f=C2=A0congruency in geometry tells us that an object B is congruent=C2=A0t= o object A if it has the same shape and size, but is allowed to flip, slide= or turn. How a path can be congruent to another path?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Agreed.=C2=A0 Th= e use of congruent in the context of pathing is confusing as the path being= addressed may not be reflected accurately by the term congruent.=

    <RG2> As = replied above.

    <RG> Ther= e are many existing RFCs that use term Congruent Path (e.g. RFC 5921, 6669)= without defining them. I suspect it is because it is well-known term. Having said that, we can add a reference for it if it helps reader.<= /span>

    GIM>> I cannot assume what was the context of = these RFCs. I've sketched a network diagram above to illustrate=C2=A0th= at a "congruent path" may well lead to out-of-band path. Is that the intention of the authors of the draft to use this protocol out-of-band= ?

    <RG2> As = replied above.

    • The last paragraph in Section 3 refers to work on iOAM:
      • <= /ul>

      =C2=A0 =C2=A0The In-Situ Operations, Administration,= and Maintenance (IOAM)
      =C2=A0 =C2=A0mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
      =C2=A0 =C2=A0SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
      =C2=A0 =C2=A0information such as timestamp in-band as part of the data pack= ets,
      =C2=A0 =C2=A0and are outside the scope of this document.

      Is iOAM in the scope of this specification? What are= the relationships between iOAM and=C2=A0draft-gandhi-spring-twamp-srpm?=

      <RG> As mentioned in the draft, IOAM is outside the scop= e.

    GIM>> Yes, but it appears that references to t= he two IOAM-related drafts have some purpose. What is it? How are these dra= fts related to=C2=A0draft-gandhi-spring-twamp-srpm?=C2=A0

    <RG2> We = can remove them if it is confusing. It is informational text (was added to = address a review comment).

    • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with=C2=A0draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?<= /u>

    <RG> Yes,= this can be Yang model. We can review draft-ietf-ippm-tw= amp-yang and add any missin= g items in a separate draft. We can also add a reference in this draft.

    GIM>> I think that theremust=C2=A0be some disc= ussion on how the new protocol is configured. If TWAMP YANG data model can = be augmented, I'd expect that being defined in=C2=A0draft-gandhi-ippm-t= wamp-srpm. But I couldn't find anything about the configuration of the protocol.= =C2=A0

    <RG2> The= Yang model extensions are not in the scope of this draft=C2=A0

    • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

    <RG> Exis= ting TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D loss measu= rement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clarify.

    GIM>> True, direct loss measurement, in fact, = is not active measurement and thus is outside the scope of Two-Way Active M= easurement Protocol (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, passive measurement method and fetching= counters can be done using numerous methods, e.g., SNMP, Netconf=C2=A0<= /u>

    <RG2> RFC= 7799 does not say using Test-packets to collect counters for direct-mod lo= ss measurement is passive.

    GIM2>> Per RFC 7799, injecting in-band test pa= ckets is the characteristic of an active measurement method. Using out-of-b= and transport, e.g., SNMP queries, would be an example of a passive measure= ment method.

    =C2=A0

    <RG3> Ok= , so you answered your own question that the direct-mode packet loss extens= ion defined is =E2=80=9Cactive measurement=E2=80=9D method.

    • Section 4.1.1 requires that

    =C2=A0 The Destination UDP port cannot be used as So= urce port, since
    =C2=A0 =C2=A0the message does not have any indication to distinguish betwee= n the
    =C2=A0 =C2=A0query and response message.

    Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Good question=C2= =A0

    <RG2> Yes= , it is unique in the domain.

    <RG> This= is user-defined and is up to the user what UDP port to provision in a doma= in.

    GIM>> So, can user configure a port number fro= m the User Ports range? Or, can the same port number be used on the same sy= stem for a number of test sessions? I find the use of UDP port numbers being underspecified.

    • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test pack= et in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test pa= cket format to perform both delay and packet loss measurement.

    <RG> Ok, = we can update the text in the next revision to indicate exact name from the= RFC 4656. We can also add text to include synthetic packet loss.=

    GIM>> I think that making it explicit would he= lp. Also, that will highlight what is being introduced by *twamp-srpm draft= s is, in fact, a new protocol to perform synthetic packet loss measurement.=C2=A0

    =C2=A0<RG2&g= t; No, it does not change anything for synthetic packet loss.=

    • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?=

    <RG> We c= an update the text in the next revision to indicate query format name from = RFC 5357.

    GIM>> I cannot find any reference to a query f= ormat in RFCs 4656/5357. Could you please quote from any of these documents= ?

    =C2=A0<RG2&g= t; It is test-packet, we will use RFC 5357 term.

    • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
    <RG> Yes. Please see section 4.1.1 and quoted below:
    =E2=80=9CFor symmetrical size que=
ry and response messages as defined in [RFC6038],=E2=80=9D=

    GIM>> RFC 6038 defines an extension to RFC 535= 7 for OPTIONAL use of the symmetrical test packets. Since *-twamp-srpm prop= osals do not use TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about that either (in part because RFC 6038 came= later), I don't see that there's any certainty in what is the sze = of a test packet used in the direct-loss measurement.=C2=A0

    =C2=A0<RG2&g= t; The test-packets as defined in these existing RFCs are used for delay an= d synthetic packet loss. The direct-mode test-packets are defined in this draft.

    GIM2>> This draft defines only a new packet fo= rmat for the direct packet loss measurement. For STAMP such a mechanism is = clearly superfluous given the Direct Measurement TLV is already defined.=

    =C2=A0

    <RG3> As= replied earlier.

    • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

    <RG> This= is same as TWAMP. There is no change.

    GIM>> Per RFC 5357, TWAMP uses only NTP format= . Is that the case for *-twamp-srpm?=C2=A0

    =C2=A0<RG2&g= t; No change in existing in what is there in RFC 5357 and RFC 8186.<= u>

    • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

    <RG> Hard= ware timestamps are recommended for SR use-cases. We can change the sentenc= e.

    GIM>> Perhaps you can propose some text, that = would be helpful.=C2=A0

    =C2=A0<RG2&g= t; Ack.

    • Section 4.1.1.1 stated that

    =C2=A0 =C2=A0A separate user-configured
    =C2=A0 =C2=A0destination UDP port is used for the delay measurement in
    =C2=A0 =C2=A0authentication mode due to the different probe message format.=

    Can that be interpreted that there could be concurre= nt authenticated and unauthenticated test sessions using this protocol? Wou= ld different authentication methods require using unique destination UDP port numbers?

    <RG> Yes,= and Yes, and these are based on provisioning.

    GIM>> But that requirement is far outside the = TWAMP, as defined in RFC 5357.

    =C2=A0<RG2&g= t; Some Session-Sender can use authenticated and some not. It is part of RF= C 5357.

    • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

    <RG> The = direct-mode loss defines new procedure for sender/reflector to collect traf= fic counters, as opposed to timestamp. The rest is the same as RFC 4656 and 5357.

    GIM>> I cannot agree with your statement "= ; The rest is the same as RFC 4656 and 5357" because the sender's = direct-loss format does not have Error Estimate field, Thus, a reflected packet does not have Sender's Error Estimate, nor Error Estimate of th= e reflector. And that, in my opinion, is another clear indication that *twa= mp-srpm drafts define a new protocol, separate from OWAMP/TWAMP.<= /u>

    =C2=A0<RG2&g= t; That field is specific to timestamps and would not apply to counters for= direct-mode loss measurement.

    • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
    • A couple of question to the following text in Section 4.1.3:<= /li>

    =C2=A0 =C2=A0The local and remote IP
    =C2=A0 =C2=A0addresses of the link are used as Source and Destination Addre= sses.
    =C2=A0 =C2=A0They can also be IPv6 link local address as probe messages are= pre-
    =C2=A0 =C2=A0routed.

      • What are the addresses of a link?

    <RG> I am= assuming this well-known (e.g. RFC 2328).

    GIM>> I am not familiar with the term "pr= e-routed". What does it mean?=C2=A0

    =C2=A0<RG2&g= t; Ensure that packets are routed over the link.

      • In which scenarios an IPv6 LLA can be used?

    <RG> I am= assuming this is well-known (e.g. RFC 5613).

    GIM>> So, LLA may be used as the source and de= stination addresses when testing an SR tunnel?=C2=A0

    =C2=A0<RG2&g= t; As mentioned this is for links.

      • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such=C2=A0a=C2=A0packet will be routed, correct? That does appear as a security threat, would you agree= ?

    <RG> Abso= lutely do not agree. It is no different than IP routed TWAMP packet as defi= ned in [RFC5357].

    GIM>> You don't agree that the processing = described cannot happen because of laws of physics or it wouldn't happe= n because no one will think of that? If the latter, I think that that is security threat.

    =C2=A0<RG2&g= t; There is no new threat like you have mentioned.

    GIM2>> Hmmm, but how the integrity of TLVs pro= posed in=C2=A0draft-gandhi-ippm-stamp-srpm can=C2=A0be protected? These are= not protected by HMAC as presented in figures 3 and 5.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    =C2=A0

    <RG3> Th= e extensions do not change the processing of these existing TLVs defined fo= r HMAC. We can add text to indicate this.

    • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the= =C2=A0format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the tw= o is used for the delay measurement in the proposed protocol?=

    <RG> The = probe query packet in the Session-Sender text packet. We can update the nam= e.

    • Section 4.2.1 states that

    =C2=A0 =C2=A0In one-way measurement mode, the probe = response message as defined in
    =C2=A0 =C2=A0Figure 6 is sent back out-of-band to the sender node ...

    Could you clarify how the responder controls that th= e response packet is sent not in-band but out-of-band?

    <RG> Plea= se refer to section 3.1 in draft-gandhi-ippm-twamp-srpm.=C2=A0 This is exis= ting behaviour for out-of-band.

    GIM>>=C2=A0draft-gandhi-ippm-twamp-srpm does n= ot specify that it defines another new protocol OWAMP Light. And it is not = clear what you reference as "this is existing behavior". Is it to reference behavior of TWAMP test packet? But the behavior of the TWAMP-= Test protocol by itself is neither in-band, nor out-of-band. It is the enca= psulation of the TWAMP test packet that makes it either in-band or out-of-b= and.=C2=A0

    =C2=A0<RG2&g= t; Right.

    GIM>> So, you believe that proposing to use th= e method described in RFC 8403 for the TWAMP packet is innovation? And what= are the benefits of using the TWAMP test packet format in the Loopback mode?

    =C2=A0<RG2&g= t; Please see the draft.

    • What is the rationale for setting TTL/Hop Limit fields always to 255 for IP= v4, MPLS, and IPv6 (per Section 4.3.1)?

    <RG> This= is as defined in Section 4.2 of RFC 5357 (Bullet 4).<= /p>

    GIM>> I believe you've misunderstood the t= ext in RFC 5357. This bullet specifies the behavior of a Session-Reflector.= It is to try to read TTL value of the received TWAMP test packet and copy the value in Sender TTL field of the reflected packet. If the Ses= sion-Reflector cannot access the TTL field, it MUST write 255 in the Sender= TTL field. So, I think that my questions still remains.

    =C2=A0<RG2&g= t; Please see Section 4.2.1 of RFC 5357.

    • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be= lieve that allowing the use of Zero UDP checksum in some scenarios, this pr= otocol introduces a security threat that must be thoroughly analyzed in the= Security Considerations section.

    <RG> This= is described in RFC 6936. It will be very specific to the UDP port provisi= oned for TWAMP. We will add reference to RFC 6936 in Security Section.

    GIM>> I don't think that the reference is = sufficient for the Securit=C2=A0Consideration. I'd expect some extended= discussion on why using zero UDP header checksum is not a security threat for *twamp-srpm=C2=A0 protocol.

    =C2=A0<RG2&g= t; Please see reply above.

    • Section 8 refers to "liveness monitoring of Links and SR Paths". = This appears as the replication of functionality provided by BFD/S-BFD prot= ocols. Is such comparison accurate? If it is, shouldn't the proposal be= also reviewed by the BFD WG?

    <RG> TWAM= P=C2=A0 probe messages are used today for synthetic packet loss which can a= lso be used to detect connection loss (performance metric). The section simply highlights this obvious metric.

    GIM>> Can you point to a document that has def= ined "TWAMP=C2=A0 probe messages are used today for synthetic packet l= oss"? Also, which document defines loss of connectivity as a performan= ce metric? Does *twamp-srpm proposes to use the new protocol to detect the lo= ss of path continuity?

    =C2=A0<RG2&g= t; For example Y.1731 has such notion of connection loss. TWAMP is used wid= ely for synthetic packet loss and is well-known. There is no change in protocol. This is reported metric.

    GIM2>> What are packet transmission frequencie= s authors envisioned for that mode? A single-digit millisecond?=C2=A0

    =C2=A0

    <RG3> It= depends on the implementation.

    • I found the Security Section of the proposed protocol inadequately terse an= d missing very important threats that this protocol introduces in the netwo= rk.

    <RG> Othe= r than referring RFC 6936 for zero checksum what else is missing? Otherwise= it is no different than RFC 8762 (STAMP).

    GIM>> I cannot see how RFC 8762 is relevant to= *twamp-srpm drafts. The use of source IP addresses, as mentioned above, ap= pears to be another security risk introduced by *-twamp-srpm drafts.=C2=A0

    =C2=A0<RG2&g= t; There is no mention of Source IP address above.

    • draft-gandhi-ippm-twamp-srpm

    As I understand it, the motivation for the Loss Meas= urement mode defined in this specification is to collect "in-profile&q= uot; counters. Is that correct? Do you see as essential for this mode that the query messages are in-band with the flow being profiled= ? In your opinion, how using an out-of-band method of collecting these coun= ters, e.g., by using ICMP multi-part=C2=A0message extension per RFC 4884, c= ould affect the accuracy comparing with the method in this protocol? How the impact changes if extended ICMP messa= ges are in-band with the profiled flow?

    =C2=A0<RG2&g= t; Yes, they need to be in-band with the flow, to collect the counter from = the right forwarding paths for the flow. Discussion of using ICMP for direct-mode loss measurement is outside the scope of this draft.=

    GIM2>> I think that the assumption "they = need to be in-band with the flow, to collect the counter from the right for= warding paths for the flow" is technically inaccurate. Otherwise, how = SNMP queries could work for decades of networking history?

    =C2=A0

    <RG3> Th= e scope of this draft is orthogonal to the out of band schemes those may ex= ist.

    =C2=A0<= u>

    Thanks,=

    Rakesh<= u>

    =C2=A0

    <RG> As m= entioned earlier, I am not sure extending ICMP to do PM is a good option he= re. Both TWAMP and OWAMP are widely deployed today for delay and synthetic loss measurement.

    GIM>> What is the reason mentioning OWAMP? Are= drafts *-twamp-srpm extend RFC 4656 OWAMP as well? Also, what you see as t= he connection between using active measurement methods to measure packet delay and packet loss, on one hand, and collecting packet c= ounters?

    =C2=A0

    <RG2> The= Session-Sender test-packet is defined in OWAMP RFC and not TWAMP RFC. Othe= r than timestamp and its format vs. counter and its format, the messages and processing are the same.

    =C2=A0

    Thanks,<= u>

    Rakesh

    =C2=A0

    =C2=A0

    • Section 3.1 introduces the new field, Sender Control Code. The format of th= e packet, as I understand it, is presented in Figure 1. When comparing with= the format of Session-Sender's test packet defined in RFC 4656 OWAMP i= n Section 4.1.2 I've noticed that there are no MBZ fields. Are these introduced by your proposal?

    <RG> It s= hows the partial message that has new field. We can update it to show the f= ull message to avoid such confusion.

    • Also, it appears that the Sequence Number field in TWAMP Session-Sender'= ;s test packet is absent in Figure 1. Is that intentional?

    <RG> It s= hows the partial message that has new field. We can update it to show the f= ull message to avoid such confusion.

    Thanks,<= u>

    Rakesh

    =C2=A0

    Regards,

    Greg

    =C2=A0Thanks=C2=A0

    =C2=A0

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gyan=C2=A0=

    =C2=A0

    On Thu, Oct 22, 2020 at 5:51 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com" target=3D"_blank">james.n.= guichard@futurewei.com> wrote:

    Dear WG:

    =C2=A0

    This message starts a 3 week WG= adoption call for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-11 ending Nove= mber 12th 2020. Please note that this document has several changes from v-10 that were requested by the SPR= ING and IPPM chairs. For this reason, the chairs have extended the adoption= call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption.

    =C2=A0

    Some background: =C2=A0<= u>

    =C2=A0

    Several review comments were re= ceived previously for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chairs considered those comments, and upon revie= w of this version of the document, determined the following:<= /p>

    =C2=A0

    =C2=A0

    These conclusions were discussed with the authors of= =C2=A0https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10 the result of which is the publication of the following two documents:

    =C2=A0

    =C2=A0

    After review of the SPRING document please indicate = support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support = (or lack thereof) as silence will not be considered as consent.

    =C2=A0

    Finally, the chairs would like = to thank the authors for their efforts in this matter.=

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno, & Joel

    =C2=A0

    _______________________________________________
    spring mailing list
    spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

    =C2=A0

    _______________________________________________
    spring mailing list
    spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

    --

    =

    Gyan Mishra

    Network Solutions Architect=C2=A0

    M 301 502-1347
    13101 Columbia Pike=C2=A0
    Silver Spring, MD

    =C2=A0

    --000000000000c4089305b59303ef-- From nobody Fri Dec 4 14:53:53 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4FB3A0E18 for ; Fri, 4 Dec 2020 14:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Qlg1UQ0DgVMk for ; Fri, 4 Dec 2020 14:53:48 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71EA83A0CDF for ; Fri, 4 Dec 2020 14:53:48 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id r9so7421099ioo.7 for ; Fri, 04 Dec 2020 14:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dH9LKQvEExbsQ2OHWc57ivdTYxyFXRHEzNlt0dE42v8=; b=kmtgM8V6xh7dorzx9zStxoBsR3xERDmUFijY30NjMtIH7swrftduEUttf9XkF1H9mq Z4VheXuI1YkC2ZGAsGbvnhTDDW2fePQmZ7cPykcGfI5oAXseJDyDY8QygcdY1Sc2Sb+e 42Co/v86BN7za4CJA1ErLsfvbtXj3CZFuYYB2eqjVpcZCS+6DT42SsUOaQW8lH3f3Ti/ 6Xo9zQ0SWsIIGNkOtz/xi3beqoWvKmDQ/WlsXXXn8sIhm9dMHrB5MHbk1LJwWJk74SxF mYV7IG+P3w0X3bQ08jNut9NvVo+XsZdNJ1ZQA/igwx8dF5XOidOfrfVrj08lqbitR14t QvNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dH9LKQvEExbsQ2OHWc57ivdTYxyFXRHEzNlt0dE42v8=; b=L1lgrWkGoZkcJVTLCm8dT7TtFzBHdF0F7hNElch8QU0T242L04yP3kDRgXxo8uE8QP XoHq7TM7HrMBjZac72zkae51+5PN/1ufwtnivwMxr5JM1PmJrvJZS4wahaK0kNoy3zSq y246U9LaO95PSvdGJiMcxoMDLT+9bJ1VYRAwQn5U33OF4fMTB+e6E0sZ84bs/hJINTR2 +dVBRPyk1l+TqTni/bz8gfsyPIsSdC/OxlxofRueIQG76Sfi5biPk9WFBHR7zelqOs9H f3EGQhJYGQegvJQ2DRI89jeJQlwNgWz/x211HeGnHvcVjpjzSqGbRswArl4E50bA2nmY KlRw== X-Gm-Message-State: AOAM531aFGy8w0guAB5VTM7r0pI/QC/+ewbFxJcyz7JqM6G9inN7Uz7S pDcVpVp629roDXlVQPq5hkTcfXY/jkRDpS85BZo= X-Google-Smtp-Source: ABdhPJyDCLQqjoHxuxALRvDoqy6DxNNQ+yAmx61sumgYUyqSEFZRiWZyLhujCIYzM4HKj4PHU2cIkabmVl17iuTNwkw= X-Received: by 2002:a05:6638:1247:: with SMTP id o7mr8942320jas.31.1607122427493; Fri, 04 Dec 2020 14:53:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Fri, 4 Dec 2020 14:53:36 -0800 Message-ID: To: Greg Mirsky Cc: IETF IPPM WG , Greg Mirsky Content-Type: multipart/alternative; boundary="00000000000066c0b605b5ab592b" Archived-At: Subject: Re: [ippm] Is loopback/direct export amplification worse than linear? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 22:53:52 -0000 --00000000000066c0b605b5ab592b Content-Type: text/plain; charset="UTF-8" thanks Greg. I hope I'm understanding you correctly these are critiques of the drafts largely unrelated to mine? On Wed, Dec 2, 2020 at 3:06 PM Greg Mirsky wrote: > Hi Martin, > thank you for highlighting some troublesome characteristics of using the > Loopback flag in IOAM. I agree that draft-ietf-ippm-ioam-flags could > tighten up the description of scenarios when the Loopback flag is used. > Also, it seems that the behavior of Direct Export > can > benefit from more clarifications. Now I've read both drafts taking notes > and present them to you below: > *draft-ietf-ippm-ioam-flags:* > > - draft-ietf-ippm-ioam-data defined IOAM as a method to record > "operational and telemetry information in the packet while the packet > traverses a path between two points in the network". It is an example of a > hybrid measurement method, per RFC 7799 classification. The introduction of > the Loopback and Active flags clearly makes IOAM into an active method and > thus it should be discussed as a protocol that originates test packets, > including potential security threats it may be used to create. > - If the purpose of the Loopback flag is producing a series of > responses from traversed nodes, then it might be much easier to use not a > copy of the original packet but a different packet to respond to the sender > (similar to CFM's LTM/LTR). That will avoid any risk of reverse-path > amplification. > - It is not clear what kind of path is expected in "a return path from > transit nodes and destination nodes towards the source (encapsulating node) > exists"? For example, if IOAM is used in an SFC environment, would Loopback > require the use of an SFP to the sender? > - It is not clear what establishes "the identity of the [IOAM] > encapsulating node". Some examples would be helpful. > - There seems to be a disconnect in handling unexpected looped IOAM > packet: > > In the second paragraph Section 4 it is stated: > "If an encapsulating node receives a looped back packet that was not > originated from the current encapsulating node, the packet is dropped." > > But in the second from the last paragraph of the same section is noted > that: > "If there is no match in the Node ID, the packet is processed like a > conventional IOAM-encapsulated packet." > > > - The following probably may be expressed using the definitions from > the IANA registry: > > An IOAM trace option that has the loopback bit set MUST have the > value '1' in the most significant bit of IOAM-Trace-Type, and '0' in > the rest of the bits of IOAM-Trace-Type. > > like that: > An IOAM Trace Option that has the Loopback bit set MUST have the > "hop_Lim and node_id in short format" bit set IOAM-Trace-Type, and MUST > have all other bits of IOAM-Trace-Type cleared. > > > - What is the value of collecting "hop_Lim and node_id in short > format" on the return path of a packet looped back by an intermediate node? > As I understand it, only that information can be collected if the Loopback > flag is set. Please correct me if that is not the case. > - Can you point where it is specified that when using the Loopback > "the packet does not have any payload"? Earlier in Section 4 action of an > intermediate node is explained: > > A loopback bit that is set indicates to the transit nodes processing > this option that they are to create a copy of the received packet and > send the copy back to the source of the packet. > > One can understand that the looped back packet is a carbon copy of the > original packet less the Loopback flag being cleared. And the actions of > the encapsulating node are described as: > The encapsulating node either generates synthetic packets with an > IOAM trace option that has the loopback flag set, or sets the loopack > flag in a subset of the in-transit data packets. > > Which suggests that, at least in the latter case, the packet with the > Loopback flag set does have a payload. > > > - One of the essential aspects of defining an active measurement > protocol is the specification of the expected rates that test packets be > generated for the intended purpose of the protocol. Some protocols provide > a mechanism to negotiate that rate either through its control-plane > component or as part of bringing the test session to Up state. I couldn't > find any discussion of the expected purpose of using the Active flag, nor > sufficient information that would help to set reasonable limits on > processing packets with the Active flag set. Also, even though the document > is on the Standards track, I find normative language in relation to the > security impact of Loopback and Active flags being underused. > - Applying rate limits throughout the IOAM domain might be cumbersome. > I think that stronger security methods must be defined making using the > Loopback and Active options more secure. For example, using authentication > to ensure the identity of the encapsulating IOAM node that imposed the > Loopback or Active option. > > *draft-ietf-ippm-ioam-direct-export* > > - Section 3.1 includes very important assumption: > > The option [DEX] can be read but not modified by transit nodes. > > That brings the question What protects the DEX option in particular and > IOAM-Option-Types in general? > > > - The description of the processing of the DEX option by > encapsulating, transit, and decapsulating nodes in an IOAM domain in all > cases states "MAY export the requested IOAM data". What are other possible > behaviors of nodes processing the DEX option? > - In the last paragraph of Section 3.1 stated: > > A transit IOAM node that does not support the DEX option SHOULD ignore > it. > > What are other allowed behaviors of a node, whether transit or > decapsulating? Report an error? Discard the packet with the DEX option? > > > - Though considerations for performance impact at a collector(s) is > sensible, it seems that the impact on the node exporting telemetry > information triggered by the DEX should also be considered. > - Applying rate limits throughout the IOAM domain might be cumbersome. > I think that there could be other methods to improve the security of the > DEX option. > - I can understand that the identity of a collector(s) of exported > information can be provisioned via the management or control plane. But I > also believe that there must be a discussion of why the Loopback option is > not a special case of the DEX option. > > Regards, > Greg > > On Sun, Nov 15, 2020 at 9:45 PM Martin Duke > wrote: > >> I recognize that the loopback and direct export drafts discuss potential >> amplification results, as a path of length N will generate N packets for >> each IOAM packet -- a linear relationship. As these are discussed in the >> draft with proposed mitigation, in an editorial sense the job is done. >> Whether giving people this kind of foot gun is a good idea is a separate >> question, but reasonable people can disagree. >> >> However, if I understand correctly, certain pathological combinations of >> IOAM namespaces could result in amplification far worse than linear. >> >> 1) Loopback loops >> Imagine there is an IOAM namespace that covers the path from Hop A to Hop >> D. There is a separate namespace entirely contained in A-D, from hop B from >> hop C. Both namespaces enable loopback. >> A >> --------------------------------------------------------D >> >> B-------------------------------C >> >> So a user packet is traveling from A to D. There will be (D-A) loopback >> packets headed towards A. The (D - C) loopback packets that generated >> between C and D will travel through the encapsulating node at C and then >> trigger further loopbacks to C. Thus the total number of packets generated >> by the single user packet is >> (D - A) + (D - C)(C - B) >> and obviousy there could be several of these smaller namespaces, or >> nested namespaces, that aggravate the amplification further. >> >> 2) Direct Export >> Direct Export potentially has even worse properties. Suppose namespace A, >> N_A hops across, direct exports to a node that is reachable across >> namespace B. Namespace B, N_B hops across, direct exports to a node >> reachable across namespace A. >> >> Thus a single user packet sent over namespace A will generate N_A packets >> that traverse Namespace B. This will, in turn, generate N_A * N_B packets >> that traverse namespace A, which in turn triggers N_A ^ 2 * N_B packets, >> and so on. >> >> In fact, if the namespaces direct export with probability exactly,1/N_A >> and 1/N_B, the same level of traffic will ping-pong infinitely. Any more >> than that, and the traffic will steadily increase to infinity. If the >> probability is 1, the growth is exponential. >> >> **************** >> >> This analysis, if correct, raises three questions that I can think of: >> - Are these corner cases plausible? >> - If so, and they occurred, would the namespace administrators >> necessarily be aware of each other? If not, I'm concerned that this is >> unsafe to deploy. >> - Do phenomena like this indicate that the design is brittle and putting >> in some "considerations" doesn't really mitigate the dangers here? >> >> Martin >> >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > --00000000000066c0b605b5ab592b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    thanks Greg.

    I hope I'm understandi= ng you correctly these are critiques of the drafts largely unrelated=C2=A0t= o mine?

    On Wed, Dec 2, 2020 at 3:06 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
    Hi Martin,<= div>thank you for highlighting some troublesome characteristics of using th= e Loopback flag in IOAM. I agree that=C2=A0draft-ietf-ippm-ioam-flags could= tighten up the description of scenarios when the Loopback flag is used. Al= so, it seems that the behavior of=C2=A0Direct Export=C2=A0can benefit from more clarifications. Now I'= ;ve read both drafts taking notes and present them to you below:
    = draft-ietf-ippm-ioam-flags:
    • draft-ietf-ippm-ioam-d= ata defined IOAM as a method to record "operational and telemetry info= rmation in the packet while the packet traverses a path between two points = in the network". It is an example of a hybrid measurement method, per = RFC 7799 classification. The introduction of the Loopback and Active flags = clearly makes IOAM into an active method and thus it should be discussed as= a protocol that originates test packets, including potential security thre= ats it may be used to create.
    • If the purpose of the Loopback fl= ag is producing a series of responses=C2=A0from traversed nodes, then it mi= ght be much easier to use not a copy of the original packet but a different= packet to respond to the sender (similar to CFM's LTM/LTR). That will = avoid any risk of reverse-path amplification.
    • It is not clear what = kind of path is expected in "a return path from transit nodes and dest= ination nodes towards the source (encapsulating node) exists"? For exa= mple, if IOAM is used in an SFC environment, would Loopback require the use= of an SFP to the sender?
    • It is not clear what establishes "th= e identity of the [IOAM] encapsulating node". Some examples would be h= elpful.
    • There seems to be a disconnect in handling unexpected loope= d IOAM packet:
    In the second paragraph Section 4 it is stated:
    "If an encapsulating node receives a looped back packet that wa= s not originated from the current encapsulating node, the packet is dropped= ."
    But in the second from the last paragraph of the = same section is noted that:
    "If there is no match in the Nod= e ID, the packet is processed like a conventional IOAM-encapsulated packet.= "
    • The following probably may be expressed us= ing the definitions from the IANA registry:
    =C2=A0 =C2=A0An IOAM t= race option that has the loopback bit set MUST have the
    =C2=A0 =C2=A0val= ue '1' in the most significant bit of IOAM-Trace-Type, and '0&#= 39; in
    =C2=A0 =C2=A0the rest of the bits of IOAM-Trace-Type.
    like that:
    =C2=A0 =C2=A0An IOAM Trace Option that has = the Loopback bit set MUST have the
    =C2=A0 =C2=A0"hop_Lim and node_i= d in short format" bit set IOAM-Trace-Type, and MUST=C2=A0
    = =C2=A0 =C2=A0have all other bits of IOAM-Trace-Type cleared.
    • What is the value of collecting "hop_Lim and node_id i= n short format" on the return path of a packet looped back by an inter= mediate node? As I understand it, only that information can be collected if= the Loopback flag is set. Please correct me if that is not the case.
      • <= li>Can you point where it is specified that when using the Loopback "t= he packet does not have any payload"? Earlier in Section 4 action of a= n intermediate node is explained:
    =C2=A0 =C2=A0A loopback bit that= is set indicates to the transit nodes processing
    =C2=A0 =C2=A0this opti= on that they are to create a copy of the received packet and
    =C2=A0 =C2= =A0send the copy back to the source of the packet.
    On= e can understand that the looped back packet is a carbon copy of the origin= al packet less the Loopback flag being cleared. And the actions of the enca= psulating node are described as:
    =C2=A0 =C2=A0The encapsulating n= ode either generates synthetic packets with an
    =C2=A0 =C2=A0IOAM trace o= ption that has the loopback flag set, or sets the loopack
    =C2=A0 =C2=A0f= lag in a subset of the in-transit data packets.
    Which= suggests that, at least in the latter case, the packet with the Loopback f= lag set does have a payload.
    • One of the essential= aspects of defining an active measurement protocol is the specification of= the expected rates that test packets be generated for the intended purpose= of the protocol. Some protocols provide a mechanism to negotiate that rate= either through its control-plane component or as part of bringing the test= session to Up state. I couldn't find any discussion of the expected pu= rpose of using the Active flag, nor sufficient information that would help = to set reasonable limits on processing packets with the Active flag set. Al= so, even though the document is on the Standards track, I find normative la= nguage in relation to the security impact of Loopback and Active flags bein= g underused.
    • Applying rate limits throughout the IOAM domain might = be cumbersome. I think that stronger security methods must be defined makin= g using=C2=A0the Loopback and Active options more secure. For example, usin= g authentication to ensure the identity of the encapsulating IOAM node that= imposed the Loopback or Active option.
    draft-ietf-ippm-ioa= m-direct-export
    • Section 3.1 includes very importa= nt assumption:
    =C2=A0 The option [DEX] can be read but not modifie= d by transit nodes.
    That brings the question What pro= tects the DEX option in particular and IOAM-Option-Types in general?
    <= /blockquote>
    • The description of the processing of the DEX option by = encapsulating, transit, and decapsulating nodes in an IOAM domain in all ca= ses states "MAY export the requested IOAM data". What are other p= ossible behaviors of nodes processing the DEX option?
    • In the last p= aragraph=C2=A0of Section 3.1 stated:
    =C2=A0 A transit IOAM node th= at does not support the DEX option SHOULD ignore it.
    =
    = What are other allowed behaviors of a node, whether transit or decapsulatin= g? Report=C2=A0an error? Discard the packet with the DEX option?
    • Though considerations for=C2=A0performance impact at=C2=A0a= collector(s) is sensible, it seems that the impact on the node exporting t= elemetry information triggered by the DEX should also be considered.
      • Applying rate limits throughout the IOAM domain might be cumbersome. I th= ink that there could be other methods to improve the security of the DEX op= tion.
    • I can understand that the identity of a collector(s) of expor= ted information can be provisioned via the management or control plane. But= I also believe that there must be a discussion of why the Loopback option = is not a special case of the DEX option.
    Regards,
    =
    Greg

    On Sun, Nov 15, 2020 at 9:45 PM Martin Duke <martin.h.duke@gmail.com> = wrote:
    I recognize that the loopback and direct export drafts discuss pot= ential amplification results, as a path of length N will generate N packets= for each IOAM packet -- a linear relationship. As these are discussed in t= he draft with proposed=C2=A0mitigation, in an editorial sense the job is do= ne. Whether giving people this kind of foot gun is a good idea is a separat= e question, but reasonable people can disagree.

    However,= if I understand correctly, certain pathological combinations of IOAM names= paces could=C2=A0result in amplification far worse=C2=A0than linear.
    <= div>
    1) Loopback loops
    Imagine there is an IOAM nam= espace that covers the path from Hop A to Hop D. There is a separate namesp= ace entirely contained in A-D, from hop B from hop C. Both namespaces enabl= e loopback.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A ----------------------------= ----------------------------D
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B----------------------= ---------C

    So a user packet is traveling from A to= D. There will be (D-A) loopback packets headed towards A. The (D - C) loop= back packets that generated between C and D will travel through the encapsu= lating=C2=A0node at C and then trigger further loopbacks to C. Thus the tot= al number of packets generated by the single user packet is
    (D - = A)=C2=A0+ (D - C)(C - B)
    and obviousy there could be several of t= hese smaller namespaces, or nested namespaces, that aggravate the amplifica= tion further.

    2) Direct Export
    Direct Ex= port potentially has even worse properties. Suppose namespace A, N_A hops a= cross, direct exports to a node that is reachable across namespace B. Names= pace B, N_B hops across, direct exports to a node reachable across namespac= e A.

    Thus a single user packet sent over namespace= A will generate N_A packets that traverse Namespace B. This will, in turn,= generate N_A * N_B packets that traverse namespace A, which in turn trigge= rs N_A ^ 2 * N_B packets, and so on.

    In fact, if t= he namespaces direct export with probability exactly,1/N_A and 1/N_B, the s= ame level of traffic will ping-pong infinitely. Any more than that, and the= traffic will steadily increase to infinity. If the probability is 1, the g= rowth is exponential.

    ****************
    <= br>
    This analysis, if correct, raises three questions that I can = think of:
    - Are these corner cases plausible?
    - If so, = and they occurred, would the namespace administrators necessarily be aware = of each other? If not, I'm concerned that this is unsafe to deploy.
    - Do phenomena like this indicate that the design is brittle and put= ting in some "considerations" doesn't really mitigate the dan= gers here?

    Martin




    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --00000000000066c0b605b5ab592b-- From nobody Fri Dec 4 16:53:20 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E06B3A1092 for ; Fri, 4 Dec 2020 16:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NaC_d8ahdT5q for ; Fri, 4 Dec 2020 16:53:16 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6664F3A0FB2 for ; Fri, 4 Dec 2020 16:53:16 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id u18so10115200lfd.9 for ; Fri, 04 Dec 2020 16:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LUJiSDcUM1GPR9Lm/8NBhHrK/48I43kcSbaaAPFlasg=; b=dTjPFnu0o9H4tIWpxmbT/+cMCmDR/mFClWTOQQ1TAsYNc2PrGYNg1n+EJ3jc9kz/kK 204qSIGNdqEjkwzqC+MGQ66ap61MxFkeh7GbsTADLxoi/hPfG+QcyMh6rJdxFbQsAxg5 mcudrWTksNH60jt4Fsdr+3kLxDiqcBsMgm9O0uOPU1yaJlY3n136/CCi2W6jgaYhq3Lf ek62iaxs7LoO5qlVFVU62Ilh2OV1STJzKL2W4fe9m/c/m86I0CkzATjUB6m74KGBND4N 1nFIBiMiKyt4vF6WlMW5I6UElyk+BIqzFprH60DNvhSnmvA37EaQ4VY4Jc9s75WTM0bl 79Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LUJiSDcUM1GPR9Lm/8NBhHrK/48I43kcSbaaAPFlasg=; b=MB/JvNy/iR5sBjU1w1jflqb8LeMYY1PEz+QkBmRFzvtEgEsLnWg9yae/bbDbnq3/6R vpP5X8Q/vCWU61Zj1evmdejMutK192AcgJ0xuGuWlDwwTri+OflLetHDNurX77iRru25 obyBEYImhXWEVtgKflhfFD8kxfWt13uKMb2vGHTjqrjgKDt3b3NqPDNhq1AsieKErmob rAqlXbbckmKLzYuONRL7W0Dkej/5t5Lyjcce8DydN6SV6GvCWhDkuzdIgRN9aResWZuU 7czVUZGYtXskyxOwKnyTgtP8bTdaC2nTwUX0D+i5oUWYktaSW7M66zfx5ZcZTDFoB3AR uk7w== X-Gm-Message-State: AOAM530VnqHbkSjo5NDeIcYfJEj6ht75fkoXguV7EB2rHZK5E3L7Wyiy hvfAZ9fAxGp6e4C4KKqhIijMGNckfhvXMkCQwT4= X-Google-Smtp-Source: ABdhPJxRwC730c6zTF5if6qM8hBy/s5O/OTOmb/1RWxXZC1egs+mkPyTzPm8lxabruoqidmZ093AKIGOgOSebO8S+wY= X-Received: by 2002:ac2:5190:: with SMTP id u16mr4291438lfi.56.1607129594189; Fri, 04 Dec 2020 16:53:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Fri, 4 Dec 2020 16:53:03 -0800 Message-ID: To: Martin Duke Cc: IETF IPPM WG , Greg Mirsky Content-Type: multipart/alternative; boundary="00000000000091dd3405b5ad0478" Archived-At: Subject: Re: [ippm] Is loopback/direct export amplification worse than linear? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 00:53:20 -0000 --00000000000091dd3405b5ad0478 Content-Type: text/plain; charset="UTF-8" Hi Martin, I thought of them as "concerns" ;) I share your concerns regarding the impact of the Loopback flag. I think that if the returned packet travels back out-of-band, not as IOAM-esque packet that might mitigate some risks associated with the Loopback. And though I don't think that the DEX draft explicitly states that the IOAM data collected on a node is exported to a collector out-of-band, i.e., not as an IOAM packet, as well, I'd like the WG to consider this approach. The rest of my notes reflect my earlier comments. Regards, Greg On Fri, Dec 4, 2020 at 2:53 PM Martin Duke wrote: > thanks Greg. > > I hope I'm understanding you correctly these are critiques of the drafts > largely unrelated to mine? > > On Wed, Dec 2, 2020 at 3:06 PM Greg Mirsky wrote: > >> Hi Martin, >> thank you for highlighting some troublesome characteristics of using the >> Loopback flag in IOAM. I agree that draft-ietf-ippm-ioam-flags could >> tighten up the description of scenarios when the Loopback flag is used. >> Also, it seems that the behavior of Direct Export >> can >> benefit from more clarifications. Now I've read both drafts taking notes >> and present them to you below: >> *draft-ietf-ippm-ioam-flags:* >> >> - draft-ietf-ippm-ioam-data defined IOAM as a method to record >> "operational and telemetry information in the packet while the packet >> traverses a path between two points in the network". It is an example of a >> hybrid measurement method, per RFC 7799 classification. The introduction of >> the Loopback and Active flags clearly makes IOAM into an active method and >> thus it should be discussed as a protocol that originates test packets, >> including potential security threats it may be used to create. >> - If the purpose of the Loopback flag is producing a series of >> responses from traversed nodes, then it might be much easier to use not a >> copy of the original packet but a different packet to respond to the sender >> (similar to CFM's LTM/LTR). That will avoid any risk of reverse-path >> amplification. >> - It is not clear what kind of path is expected in "a return path >> from transit nodes and destination nodes towards the source (encapsulating >> node) exists"? For example, if IOAM is used in an SFC environment, would >> Loopback require the use of an SFP to the sender? >> - It is not clear what establishes "the identity of the [IOAM] >> encapsulating node". Some examples would be helpful. >> - There seems to be a disconnect in handling unexpected looped IOAM >> packet: >> >> In the second paragraph Section 4 it is stated: >> "If an encapsulating node receives a looped back packet that was not >> originated from the current encapsulating node, the packet is dropped." >> >> But in the second from the last paragraph of the same section is noted >> that: >> "If there is no match in the Node ID, the packet is processed like a >> conventional IOAM-encapsulated packet." >> >> >> - The following probably may be expressed using the definitions from >> the IANA registry: >> >> An IOAM trace option that has the loopback bit set MUST have the >> value '1' in the most significant bit of IOAM-Trace-Type, and '0' in >> the rest of the bits of IOAM-Trace-Type. >> >> like that: >> An IOAM Trace Option that has the Loopback bit set MUST have the >> "hop_Lim and node_id in short format" bit set IOAM-Trace-Type, and >> MUST >> have all other bits of IOAM-Trace-Type cleared. >> >> >> - What is the value of collecting "hop_Lim and node_id in short >> format" on the return path of a packet looped back by an intermediate node? >> As I understand it, only that information can be collected if the Loopback >> flag is set. Please correct me if that is not the case. >> - Can you point where it is specified that when using the Loopback >> "the packet does not have any payload"? Earlier in Section 4 action of an >> intermediate node is explained: >> >> A loopback bit that is set indicates to the transit nodes processing >> this option that they are to create a copy of the received packet and >> send the copy back to the source of the packet. >> >> One can understand that the looped back packet is a carbon copy of the >> original packet less the Loopback flag being cleared. And the actions of >> the encapsulating node are described as: >> The encapsulating node either generates synthetic packets with an >> IOAM trace option that has the loopback flag set, or sets the loopack >> flag in a subset of the in-transit data packets. >> >> Which suggests that, at least in the latter case, the packet with the >> Loopback flag set does have a payload. >> >> >> - One of the essential aspects of defining an active measurement >> protocol is the specification of the expected rates that test packets be >> generated for the intended purpose of the protocol. Some protocols provide >> a mechanism to negotiate that rate either through its control-plane >> component or as part of bringing the test session to Up state. I couldn't >> find any discussion of the expected purpose of using the Active flag, nor >> sufficient information that would help to set reasonable limits on >> processing packets with the Active flag set. Also, even though the document >> is on the Standards track, I find normative language in relation to the >> security impact of Loopback and Active flags being underused. >> - Applying rate limits throughout the IOAM domain might be >> cumbersome. I think that stronger security methods must be defined making >> using the Loopback and Active options more secure. For example, using >> authentication to ensure the identity of the encapsulating IOAM node that >> imposed the Loopback or Active option. >> >> *draft-ietf-ippm-ioam-direct-export* >> >> - Section 3.1 includes very important assumption: >> >> The option [DEX] can be read but not modified by transit nodes. >> >> That brings the question What protects the DEX option in particular and >> IOAM-Option-Types in general? >> >> >> - The description of the processing of the DEX option by >> encapsulating, transit, and decapsulating nodes in an IOAM domain in all >> cases states "MAY export the requested IOAM data". What are other possible >> behaviors of nodes processing the DEX option? >> - In the last paragraph of Section 3.1 stated: >> >> A transit IOAM node that does not support the DEX option SHOULD ignore >> it. >> >> What are other allowed behaviors of a node, whether transit or >> decapsulating? Report an error? Discard the packet with the DEX option? >> >> >> - Though considerations for performance impact at a collector(s) is >> sensible, it seems that the impact on the node exporting telemetry >> information triggered by the DEX should also be considered. >> - Applying rate limits throughout the IOAM domain might be >> cumbersome. I think that there could be other methods to improve the >> security of the DEX option. >> - I can understand that the identity of a collector(s) of exported >> information can be provisioned via the management or control plane. But I >> also believe that there must be a discussion of why the Loopback option is >> not a special case of the DEX option. >> >> Regards, >> Greg >> >> On Sun, Nov 15, 2020 at 9:45 PM Martin Duke >> wrote: >> >>> I recognize that the loopback and direct export drafts discuss potential >>> amplification results, as a path of length N will generate N packets for >>> each IOAM packet -- a linear relationship. As these are discussed in the >>> draft with proposed mitigation, in an editorial sense the job is done. >>> Whether giving people this kind of foot gun is a good idea is a separate >>> question, but reasonable people can disagree. >>> >>> However, if I understand correctly, certain pathological combinations of >>> IOAM namespaces could result in amplification far worse than linear. >>> >>> 1) Loopback loops >>> Imagine there is an IOAM namespace that covers the path from Hop A to >>> Hop D. There is a separate namespace entirely contained in A-D, from hop B >>> from hop C. Both namespaces enable loopback. >>> A >>> --------------------------------------------------------D >>> >>> B-------------------------------C >>> >>> So a user packet is traveling from A to D. There will be (D-A) loopback >>> packets headed towards A. The (D - C) loopback packets that generated >>> between C and D will travel through the encapsulating node at C and then >>> trigger further loopbacks to C. Thus the total number of packets generated >>> by the single user packet is >>> (D - A) + (D - C)(C - B) >>> and obviousy there could be several of these smaller namespaces, or >>> nested namespaces, that aggravate the amplification further. >>> >>> 2) Direct Export >>> Direct Export potentially has even worse properties. Suppose namespace >>> A, N_A hops across, direct exports to a node that is reachable across >>> namespace B. Namespace B, N_B hops across, direct exports to a node >>> reachable across namespace A. >>> >>> Thus a single user packet sent over namespace A will generate N_A >>> packets that traverse Namespace B. This will, in turn, generate N_A * N_B >>> packets that traverse namespace A, which in turn triggers N_A ^ 2 * N_B >>> packets, and so on. >>> >>> In fact, if the namespaces direct export with probability exactly,1/N_A >>> and 1/N_B, the same level of traffic will ping-pong infinitely. Any more >>> than that, and the traffic will steadily increase to infinity. If the >>> probability is 1, the growth is exponential. >>> >>> **************** >>> >>> This analysis, if correct, raises three questions that I can think of: >>> - Are these corner cases plausible? >>> - If so, and they occurred, would the namespace administrators >>> necessarily be aware of each other? If not, I'm concerned that this is >>> unsafe to deploy. >>> - Do phenomena like this indicate that the design is brittle and putting >>> in some "considerations" doesn't really mitigate the dangers here? >>> >>> Martin >>> >>> >>> >>> >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> >> --00000000000091dd3405b5ad0478 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Martin,
    I thought of them as "concerns" ;= )
    I share your concerns=C2=A0regarding the impact of the Loopback= flag. I think that if the returned packet travels back out-of-band, not as= IOAM-esque packet that might mitigate some risks associated with the Loopb= ack. And though I don't think that the DEX draft explicitly states that= the IOAM data collected on a node is exported to a collector out-of-band, = i.e., not as an IOAM packet, as well, I'd like the WG to consider this = approach.
    The rest of my notes reflect my earlier=C2=A0comments.<= /div>

    Regards,
    Greg

    On Fri, Dec 4, 2020 = at 2:53 PM Martin Duke <marti= n.h.duke@gmail.com> wrote:
    thanks Greg.

    I hope I= 'm understanding you correctly these are critiques of the drafts largel= y unrelated=C2=A0to mine?

    On Wed, Dec 2, 2020 at 3:06 PM Greg Mirsky &= lt;gregimirsky@g= mail.com> wrote:
    Hi Martin,
    thank you for highlighting some tro= ublesome characteristics of using the Loopback flag in IOAM. I agree that= =C2=A0draft-ietf-ippm-ioam-flags could tighten up the description of scenar= ios when the Loopback flag is used. Also, it seems that the behavior of=C2= =A0Direct Export=C2=A0can bene= fit from more clarifications. Now I've read both drafts taking notes an= d present them to you below:
    draft-ietf-ippm-ioam-flags:
    • draft-ietf-ippm-ioam-data defined IOAM as a method to reco= rd "operational and telemetry information in the packet while the pack= et traverses a path between two points in the network". It is an examp= le of a hybrid measurement method, per RFC 7799 classification. The introdu= ction of the Loopback and Active flags clearly makes IOAM into an active me= thod and thus it should be discussed as a protocol that originates test pac= kets, including potential security threats it may be used to create.
    • If the purpose of the Loopback flag is producing a series of response= s=C2=A0from traversed nodes, then it might be much easier to use not a copy= of the original packet but a different packet to respond to the sender (si= milar to CFM's LTM/LTR). That will avoid any risk of reverse-path ampli= fication.
    • It is not clear what kind of path is expected in "a = return path from transit nodes and destination nodes towards the source (en= capsulating node) exists"? For example, if IOAM is used in an SFC envi= ronment, would Loopback require the use of an SFP to the sender?
    • It= is not clear what establishes "the identity of the [IOAM] encapsulati= ng node". Some examples would be helpful.
    • There seems to be a = disconnect in handling unexpected looped IOAM packet:
    In the secon= d paragraph Section 4 it is stated:
    "If an encapsulating nod= e receives a looped back packet that was not originated from the current en= capsulating node, the packet is dropped."
    But in the= second from the last paragraph of the same section is noted that:
    "If there is no match in the Node ID, the packet is processed like a= conventional IOAM-encapsulated packet."
    • The= following probably may be expressed using the definitions from the IANA re= gistry:
    =C2=A0 =C2=A0An IOAM trace option that has the loopback bi= t set MUST have the
    =C2=A0 =C2=A0value '1' in the most significa= nt bit of IOAM-Trace-Type, and '0' in
    =C2=A0 =C2=A0the rest of t= he bits of IOAM-Trace-Type.
    like that:
    =C2= =A0 =C2=A0An IOAM Trace Option that has the Loopback bit set MUST have the<= br>=C2=A0 =C2=A0"hop_Lim and node_id in short format" bit set IOA= M-Trace-Type, and MUST=C2=A0
    =C2=A0 =C2=A0have all other bits of = IOAM-Trace-Type cleared.
    • What is the value of= collecting "hop_Lim and node_id in short format" on the return p= ath of a packet looped back by an intermediate node? As I understand it, on= ly that information can be collected if the Loopback flag is set. Please co= rrect me if that is not the case.
    • Can you point where it is specifi= ed that when using the Loopback "the packet does not have any payload&= quot;? Earlier in Section 4 action of an intermediate node is explained:
    One can understand that the looped back= packet is a carbon copy of the original packet less the Loopback flag bein= g cleared. And the actions of the encapsulating node are described as:
    =C2=A0 =C2=A0The encapsulating node either generates synthetic packet= s with an
    =C2=A0 =C2=A0IOAM trace option that has the loopback flag set,= or sets the loopack
    =C2=A0 =C2=A0flag in a subset of the in-transit dat= a packets.
    Which suggests that, at least in the latte= r case, the packet with the Loopback flag set does have a payload.
    • One of the essential aspects of defining an active measur= ement protocol is the specification of the expected rates that test packets= be generated for the intended purpose of the protocol. Some protocols prov= ide a mechanism to negotiate that rate either through its control-plane com= ponent or as part of bringing the test session to Up state. I couldn't = find any discussion of the expected purpose of using the Active flag, nor s= ufficient information that would help to set reasonable limits on processin= g packets with the Active flag set. Also, even though the document is on th= e Standards track, I find normative language in relation to the security im= pact of Loopback and Active flags being underused.
    • Applying rate li= mits throughout the IOAM domain might be cumbersome. I think that stronger = security methods must be defined making using=C2=A0the Loopback and Active = options more secure. For example, using authentication to ensure the identi= ty of the encapsulating IOAM node that imposed the Loopback or Active optio= n.
    draft-ietf-ippm-ioam-direct-export
  • Section 3.1 includes very important assumption:
    • =C2=A0 The op= tion [DEX] can be read but not modified by transit nodes.
    =
    That brings the question What protects the DEX option in particular an= d IOAM-Option-Types in general?
    • The description o= f the processing of the DEX option by encapsulating, transit, and decapsula= ting nodes in an IOAM domain in all cases states "MAY export the reque= sted IOAM data". What are other possible behaviors of nodes processing= the DEX option?
    • In the last paragraph=C2=A0of Section 3.1 stated:<= /li>
    =C2=A0 A transit IOAM node that does not support the DEX option SH= OULD ignore it.
    What are other allowed behaviors of a= node, whether transit or decapsulating? Report=C2=A0an error? Discard the = packet with the DEX option?
    • Though considerations= for=C2=A0performance impact at=C2=A0a collector(s) is sensible, it seems t= hat the impact on the node exporting telemetry information triggered by the= DEX should also be considered.
    • Applying rate limits throughout the= IOAM domain might be cumbersome. I think that there could be other methods= to improve the security of the DEX option.
    • I can understand that t= he identity of a collector(s) of exported information can be provisioned vi= a the management or control plane. But I also believe that there must be a = discussion of why the Loopback option is not a special case of the DEX opti= on.
    Regards,
    Greg

    On Sun, Nov 15, 2020 at 9:45= PM Martin Duke <martin.h.duke@gmail.com> wrote:
    I recognize that the loopback= and direct export drafts discuss potential amplification results, as a pat= h of length N will generate N packets for each IOAM packet -- a linear rela= tionship. As these are discussed in the draft with proposed=C2=A0mitigation= , in an editorial sense the job is done. Whether giving people this kind of= foot gun is a good idea is a separate question, but reasonable people can = disagree.

    However, if I understand correctly, certain pa= thological combinations of IOAM namespaces could=C2=A0result in amplificati= on far worse=C2=A0than linear.

    1) Loopback loops
    Imagine there is an IOAM namespace that covers the path from Hop A= to Hop D. There is a separate namespace entirely contained in A-D, from ho= p B from hop C. Both namespaces enable loopback.
    =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0A --------------------------------------------------------D
    =
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0B-------------------------------C

    So a user packet is traveling from A to D. There will be (D-A) loopback pa= ckets headed towards A. The (D - C) loopback packets that generated between= C and D will travel through the encapsulating=C2=A0node at C and then trig= ger further loopbacks to C. Thus the total number of packets generated by t= he single user packet is
    (D - A)=C2=A0+ (D - C)(C - B)
    = and obviousy there could be several of these smaller namespaces, or nested = namespaces, that aggravate the amplification further.

    <= div>2) Direct Export
    Direct Export potentially has even worse pro= perties. Suppose namespace A, N_A hops across, direct exports to a node tha= t is reachable across namespace B. Namespace B, N_B hops across, direct exp= orts to a node reachable across namespace A.

    Thus = a single user packet sent over namespace A will generate N_A packets that t= raverse Namespace B. This will, in turn, generate N_A * N_B packets that tr= averse namespace A, which in turn triggers N_A ^ 2 * N_B packets, and so on= .

    In fact, if the namespaces direct export with pr= obability exactly,1/N_A and 1/N_B, the same level of traffic will ping-pong= infinitely. Any more than that, and the traffic will steadily increase to = infinity. If the probability is 1, the growth is exponential.
    ****************

    This analysis, if cor= rect, raises three questions that I can think of:
    - Are these cor= ner cases plausible?
    - If so, and they occurred, would the namesp= ace administrators necessarily be aware of each other? If not, I'm conc= erned that this is unsafe to deploy.
    - Do phenomena like this ind= icate that the design is brittle and putting in some "considerations&q= uot; doesn't really mitigate the dangers here?

    Martin




    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --00000000000091dd3405b5ad0478-- From nobody Fri Dec 4 17:12:45 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943B93A1124 for ; Fri, 4 Dec 2020 17:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YeB93MjADkRC for ; Fri, 4 Dec 2020 17:12:41 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244833A1121 for ; Fri, 4 Dec 2020 17:12:40 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id y5so7678849iow.5 for ; Fri, 04 Dec 2020 17:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OUrh1S2mU/DhCsnnyjX+v+UdGt5v8DzUZPAB9gv3iTI=; b=o+VZkBAaq3LyYH0X+ZNNejLMtgc2LxoiL1WxemeYCijI3CBVIiA5Lfea4eKQqwnfr9 uuZ27w0ZTiNjV/xUeUtRu+RrOLsRrgemyOUyWUZ21HTTMaQo/K4hOuPNKOP9SJYBapYU HiaFcnCZDL62gQlUxbHKPhafjFuuszySl9LcXIbvc+9Vexst8vawii2GB1nyxnf+NkfP wtmhK+c5ms5Whg6W4YQZbrqKY8HevjKMuFAn5UJTZpfWPvqe7TkWgAT4fTU4VcNRXbee 0/XyQgLbjM1SQdUitaP0v9aMRDrUQWuKLiRlNvU29p7eSDa8tWNfTzJkRrcEqpnCRvZd 24Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OUrh1S2mU/DhCsnnyjX+v+UdGt5v8DzUZPAB9gv3iTI=; b=RoS8vy5RZIWlZzlL3eDSsD/+Evn5YDs3s20DJOZMWvvUoM7gWmEbuGNG9LSGoewSoQ l/doawLc6OS4CvFKPMFtHDN7kKjQEuHhKEF/EvQU4XWigB5im+gtcBR0q0RRlVf2Kwss O78yK9ymHHcsDEuojy+CYzIIFHu8116cOV5Kt3PDazVoaSASCnN+urx+FidiOSJBOSC0 XW7uynyVqo/4hNcWpV9fGCu44sMcRLKicAjLseef6ml/11DhWzVUbJqNN6uKAyolC7Kb 8ircRY/erRietW6fud9ePwpWpyZ3UY1W/sGN4xoT0qfYUHuMx57dYADoeVfdFRMOTGhc qjUQ== X-Gm-Message-State: AOAM532L3nT5xLtwQ/TVzqnEf/QE6ojSU1c1jv0yc2bTkcLcDTVlfqaq rpBV21hOFhjxxXTQBoXvSQEGe7dNmkjmPm69lak= X-Google-Smtp-Source: ABdhPJxdu18GojfJT0Vlp1YIORbV0ALrIpOF1VRFefolAkcrAvYXu61jzFIKqjHTD33Okq4KPiT89hJuD/pDxCZacbM= X-Received: by 2002:a02:a88a:: with SMTP id l10mr9575518jam.95.1607130760102; Fri, 04 Dec 2020 17:12:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Fri, 4 Dec 2020 17:12:29 -0800 Message-ID: To: Greg Mirsky Cc: IETF IPPM WG , Greg Mirsky Content-Type: multipart/alternative; boundary="0000000000001048c505b5ad4ae2" Archived-At: Subject: Re: [ippm] Is loopback/direct export amplification worse than linear? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 01:12:44 -0000 --0000000000001048c505b5ad4ae2 Content-Type: text/plain; charset="UTF-8" My argument is that it doesn't matter if the DEX is non-IOAM; the point is if the signature of this packet happens to match the criteria on some other IOAM domain, we end up in trouble. On Fri, Dec 4, 2020 at 4:53 PM Greg Mirsky wrote: > Hi Martin, > I thought of them as "concerns" ;) > I share your concerns regarding the impact of the Loopback flag. I think > that if the returned packet travels back out-of-band, not as IOAM-esque > packet that might mitigate some risks associated with the Loopback. And > though I don't think that the DEX draft explicitly states that the IOAM > data collected on a node is exported to a collector out-of-band, i.e., not > as an IOAM packet, as well, I'd like the WG to consider this approach. > The rest of my notes reflect my earlier comments. > > Regards, > Greg > > On Fri, Dec 4, 2020 at 2:53 PM Martin Duke > wrote: > >> thanks Greg. >> >> I hope I'm understanding you correctly these are critiques of the drafts >> largely unrelated to mine? >> >> On Wed, Dec 2, 2020 at 3:06 PM Greg Mirsky wrote: >> >>> Hi Martin, >>> thank you for highlighting some troublesome characteristics of using the >>> Loopback flag in IOAM. I agree that draft-ietf-ippm-ioam-flags could >>> tighten up the description of scenarios when the Loopback flag is used. >>> Also, it seems that the behavior of Direct Export >>> can >>> benefit from more clarifications. Now I've read both drafts taking notes >>> and present them to you below: >>> *draft-ietf-ippm-ioam-flags:* >>> >>> - draft-ietf-ippm-ioam-data defined IOAM as a method to record >>> "operational and telemetry information in the packet while the packet >>> traverses a path between two points in the network". It is an example of a >>> hybrid measurement method, per RFC 7799 classification. The introduction of >>> the Loopback and Active flags clearly makes IOAM into an active method and >>> thus it should be discussed as a protocol that originates test packets, >>> including potential security threats it may be used to create. >>> - If the purpose of the Loopback flag is producing a series of >>> responses from traversed nodes, then it might be much easier to use not a >>> copy of the original packet but a different packet to respond to the sender >>> (similar to CFM's LTM/LTR). That will avoid any risk of reverse-path >>> amplification. >>> - It is not clear what kind of path is expected in "a return path >>> from transit nodes and destination nodes towards the source (encapsulating >>> node) exists"? For example, if IOAM is used in an SFC environment, would >>> Loopback require the use of an SFP to the sender? >>> - It is not clear what establishes "the identity of the [IOAM] >>> encapsulating node". Some examples would be helpful. >>> - There seems to be a disconnect in handling unexpected looped IOAM >>> packet: >>> >>> In the second paragraph Section 4 it is stated: >>> "If an encapsulating node receives a looped back packet that was not >>> originated from the current encapsulating node, the packet is dropped." >>> >>> But in the second from the last paragraph of the same section is noted >>> that: >>> "If there is no match in the Node ID, the packet is processed like a >>> conventional IOAM-encapsulated packet." >>> >>> >>> - The following probably may be expressed using the definitions from >>> the IANA registry: >>> >>> An IOAM trace option that has the loopback bit set MUST have the >>> value '1' in the most significant bit of IOAM-Trace-Type, and '0' in >>> the rest of the bits of IOAM-Trace-Type. >>> >>> like that: >>> An IOAM Trace Option that has the Loopback bit set MUST have the >>> "hop_Lim and node_id in short format" bit set IOAM-Trace-Type, and >>> MUST >>> have all other bits of IOAM-Trace-Type cleared. >>> >>> >>> - What is the value of collecting "hop_Lim and node_id in short >>> format" on the return path of a packet looped back by an intermediate node? >>> As I understand it, only that information can be collected if the Loopback >>> flag is set. Please correct me if that is not the case. >>> - Can you point where it is specified that when using the Loopback >>> "the packet does not have any payload"? Earlier in Section 4 action of an >>> intermediate node is explained: >>> >>> A loopback bit that is set indicates to the transit nodes processing >>> this option that they are to create a copy of the received packet and >>> send the copy back to the source of the packet. >>> >>> One can understand that the looped back packet is a carbon copy of the >>> original packet less the Loopback flag being cleared. And the actions of >>> the encapsulating node are described as: >>> The encapsulating node either generates synthetic packets with an >>> IOAM trace option that has the loopback flag set, or sets the loopack >>> flag in a subset of the in-transit data packets. >>> >>> Which suggests that, at least in the latter case, the packet with the >>> Loopback flag set does have a payload. >>> >>> >>> - One of the essential aspects of defining an active measurement >>> protocol is the specification of the expected rates that test packets be >>> generated for the intended purpose of the protocol. Some protocols provide >>> a mechanism to negotiate that rate either through its control-plane >>> component or as part of bringing the test session to Up state. I couldn't >>> find any discussion of the expected purpose of using the Active flag, nor >>> sufficient information that would help to set reasonable limits on >>> processing packets with the Active flag set. Also, even though the document >>> is on the Standards track, I find normative language in relation to the >>> security impact of Loopback and Active flags being underused. >>> - Applying rate limits throughout the IOAM domain might be >>> cumbersome. I think that stronger security methods must be defined making >>> using the Loopback and Active options more secure. For example, using >>> authentication to ensure the identity of the encapsulating IOAM node that >>> imposed the Loopback or Active option. >>> >>> *draft-ietf-ippm-ioam-direct-export* >>> >>> - Section 3.1 includes very important assumption: >>> >>> The option [DEX] can be read but not modified by transit nodes. >>> >>> That brings the question What protects the DEX option in particular and >>> IOAM-Option-Types in general? >>> >>> >>> - The description of the processing of the DEX option by >>> encapsulating, transit, and decapsulating nodes in an IOAM domain in all >>> cases states "MAY export the requested IOAM data". What are other possible >>> behaviors of nodes processing the DEX option? >>> - In the last paragraph of Section 3.1 stated: >>> >>> A transit IOAM node that does not support the DEX option SHOULD ignore >>> it. >>> >>> What are other allowed behaviors of a node, whether transit or >>> decapsulating? Report an error? Discard the packet with the DEX option? >>> >>> >>> - Though considerations for performance impact at a collector(s) is >>> sensible, it seems that the impact on the node exporting telemetry >>> information triggered by the DEX should also be considered. >>> - Applying rate limits throughout the IOAM domain might be >>> cumbersome. I think that there could be other methods to improve the >>> security of the DEX option. >>> - I can understand that the identity of a collector(s) of exported >>> information can be provisioned via the management or control plane. But I >>> also believe that there must be a discussion of why the Loopback option is >>> not a special case of the DEX option. >>> >>> Regards, >>> Greg >>> >>> On Sun, Nov 15, 2020 at 9:45 PM Martin Duke >>> wrote: >>> >>>> I recognize that the loopback and direct export drafts discuss >>>> potential amplification results, as a path of length N will generate N >>>> packets for each IOAM packet -- a linear relationship. As these are >>>> discussed in the draft with proposed mitigation, in an editorial sense the >>>> job is done. Whether giving people this kind of foot gun is a good idea is >>>> a separate question, but reasonable people can disagree. >>>> >>>> However, if I understand correctly, certain pathological combinations >>>> of IOAM namespaces could result in amplification far worse than linear. >>>> >>>> 1) Loopback loops >>>> Imagine there is an IOAM namespace that covers the path from Hop A to >>>> Hop D. There is a separate namespace entirely contained in A-D, from hop B >>>> from hop C. Both namespaces enable loopback. >>>> A >>>> --------------------------------------------------------D >>>> >>>> B-------------------------------C >>>> >>>> So a user packet is traveling from A to D. There will be (D-A) loopback >>>> packets headed towards A. The (D - C) loopback packets that generated >>>> between C and D will travel through the encapsulating node at C and then >>>> trigger further loopbacks to C. Thus the total number of packets generated >>>> by the single user packet is >>>> (D - A) + (D - C)(C - B) >>>> and obviousy there could be several of these smaller namespaces, or >>>> nested namespaces, that aggravate the amplification further. >>>> >>>> 2) Direct Export >>>> Direct Export potentially has even worse properties. Suppose namespace >>>> A, N_A hops across, direct exports to a node that is reachable across >>>> namespace B. Namespace B, N_B hops across, direct exports to a node >>>> reachable across namespace A. >>>> >>>> Thus a single user packet sent over namespace A will generate N_A >>>> packets that traverse Namespace B. This will, in turn, generate N_A * N_B >>>> packets that traverse namespace A, which in turn triggers N_A ^ 2 * N_B >>>> packets, and so on. >>>> >>>> In fact, if the namespaces direct export with probability exactly,1/N_A >>>> and 1/N_B, the same level of traffic will ping-pong infinitely. Any more >>>> than that, and the traffic will steadily increase to infinity. If the >>>> probability is 1, the growth is exponential. >>>> >>>> **************** >>>> >>>> This analysis, if correct, raises three questions that I can think of: >>>> - Are these corner cases plausible? >>>> - If so, and they occurred, would the namespace administrators >>>> necessarily be aware of each other? If not, I'm concerned that this is >>>> unsafe to deploy. >>>> - Do phenomena like this indicate that the design is brittle and >>>> putting in some "considerations" doesn't really mitigate the dangers here? >>>> >>>> Martin >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> ippm mailing list >>>> ippm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ippm >>>> >>> --0000000000001048c505b5ad4ae2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    My argument is that it doesn't matter if the DEX is no= n-IOAM; the point is if the signature of this packet happens to match the c= riteria on some other IOAM domain, we end up in trouble.

    On Fri, Dec 4, 2020= at 4:53 PM Greg Mirsky <gregim= irsky@gmail.com> wrote:
    Hi Martin,
    I thought of them as "c= oncerns" ;)
    I share your concerns=C2=A0regarding the impact = of the Loopback flag. I think that if the returned packet travels back out-= of-band, not as IOAM-esque packet that might mitigate some risks associated= with the Loopback. And though I don't think that the DEX draft explici= tly states that the IOAM data collected on a node is exported to a collecto= r out-of-band, i.e., not as an IOAM packet, as well, I'd like the WG to= consider this approach.
    The rest of my notes reflect my earlier= =C2=A0comments.

    Regards,
    Greg

    On Fr= i, Dec 4, 2020 at 2:53 PM Martin Duke <martin.h.duke@gmail.com> wrote:
    thanks = Greg.

    I hope I'm understanding you correctly these a= re critiques of the drafts largely unrelated=C2=A0to mine?

    <= div class=3D"gmail_quote">
    On Wed, Dec= 2, 2020 at 3:06 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
    Hi Martin,
    th= ank you for highlighting some troublesome characteristics of using the Loop= back flag in IOAM. I agree that=C2=A0draft-ietf-ippm-ioam-flags could tight= en up the description of scenarios when the Loopback flag is used. Also, it= seems that the behavior of=C2=A0D= irect Export=C2=A0can benefit from more clarifications. Now I've re= ad both drafts taking notes and present them to you below:
    dra= ft-ietf-ippm-ioam-flags:
    • draft-ietf-ippm-ioam-data de= fined IOAM as a method to record "operational and telemetry informatio= n in the packet while the packet traverses a path between two points in the= network". It is an example of a hybrid measurement method, per RFC 77= 99 classification. The introduction of the Loopback and Active flags clearl= y makes IOAM into an active method and thus it should be discussed as a pro= tocol that originates test packets, including potential security threats it= may be used to create.
    • If the purpose of the Loopback flag is = producing a series of responses=C2=A0from traversed nodes, then it might be= much easier to use not a copy of the original packet but a different packe= t to respond to the sender (similar to CFM's LTM/LTR). That will avoid = any risk of reverse-path amplification.
    • It is not clear what kind o= f path is expected in "a return path from transit nodes and destinatio= n nodes towards the source (encapsulating node) exists"? For example, = if IOAM is used in an SFC environment, would Loopback require the use of an= SFP to the sender?
    • It is not clear what establishes "the iden= tity of the [IOAM] encapsulating node". Some examples would be helpful= .
    • There seems to be a disconnect in handling unexpected looped IOAM= packet:
    In the second paragraph Section 4 it is stated:
    "If an encapsulating node receives a looped back packet that was not = originated from the current encapsulating node, the packet is dropped."= ;
    But in the second from the last paragraph of the same s= ection is noted that:
    "If there is no match in the Node ID, = the packet is processed like a conventional IOAM-encapsulated packet."=
    • The following probably may be expressed using th= e definitions from the IANA registry:
    =C2=A0 =C2=A0An IOAM trace o= ption that has the loopback bit set MUST have the
    =C2=A0 =C2=A0value = 9;1' in the most significant bit of IOAM-Trace-Type, and '0' in=
    =C2=A0 =C2=A0the rest of the bits of IOAM-Trace-Type.
    =
    like that:
    =C2=A0 =C2=A0An IOAM Trace Option that has the Lo= opback bit set MUST have the
    =C2=A0 =C2=A0"hop_Lim and node_id in s= hort format" bit set IOAM-Trace-Type, and MUST=C2=A0
    =C2=A0 = =C2=A0have all other bits of IOAM-Trace-Type cleared.
    • What is the value of collecting "hop_Lim and node_id in short= format" on the return path of a packet looped back by an intermediate= node? As I understand it, only that information can be collected if the Lo= opback flag is set. Please correct me if that is not the case.
    • Can = you point where it is specified that when using the Loopback "the pack= et does not have any payload"? Earlier in Section 4 action of an inter= mediate node is explained:
    =C2=A0 =C2=A0A loopback bit that is set= indicates to the transit nodes processing
    =C2=A0 =C2=A0this option that= they are to create a copy of the received packet and
    =C2=A0 =C2=A0send = the copy back to the source of the packet.
    One can un= derstand that the looped back packet is a carbon copy of the original packe= t less the Loopback flag being cleared. And the actions of the encapsulatin= g node are described as:
    =C2=A0 =C2=A0The encapsulating node eith= er generates synthetic packets with an
    =C2=A0 =C2=A0IOAM trace option th= at has the loopback flag set, or sets the loopack
    =C2=A0 =C2=A0flag in a= subset of the in-transit data packets.
    Which suggest= s that, at least in the latter case, the packet with the Loopback flag set = does have a payload.
    • One of the essential aspects= of defining an active measurement protocol is the specification of the exp= ected rates that test packets be generated for the intended purpose of the = protocol. Some protocols provide a mechanism to negotiate that rate either = through its control-plane component or as part of bringing the test session= to Up state. I couldn't find any discussion of the expected purpose of= using the Active flag, nor sufficient information that would help to set r= easonable limits on processing packets with the Active flag set. Also, even= though the document is on the Standards track, I find normative language i= n relation to the security impact of Loopback and Active flags being underu= sed.
    • Applying rate limits throughout the IOAM domain might be cumbe= rsome. I think that stronger security methods must be defined making using= =C2=A0the Loopback and Active options more secure. For example, using authe= ntication to ensure the identity of the encapsulating IOAM node that impose= d the Loopback or Active option.
    draft-ietf-ippm-ioam-direc= t-export
    • Section 3.1 includes very important assu= mption:
    =C2=A0 The option [DEX] can be read but not modified by tr= ansit nodes.
    That brings the question What protects t= he DEX option in particular and IOAM-Option-Types in general?
    • The description of the processing of the DEX option by encapsu= lating, transit, and decapsulating nodes in an IOAM domain in all cases sta= tes "MAY export the requested IOAM data". What are other possible= behaviors of nodes processing the DEX option?
    • In the last paragrap= h=C2=A0of Section 3.1 stated:
    =C2=A0 A transit IOAM node that does= not support the DEX option SHOULD ignore it.
    What ar= e other allowed behaviors of a node, whether transit or decapsulating? Repo= rt=C2=A0an error? Discard the packet with the DEX option?
    • Though considerations for=C2=A0performance impact at=C2=A0a collec= tor(s) is sensible, it seems that the impact on the node exporting telemetr= y information triggered by the DEX should also be considered.
    • Apply= ing rate limits throughout the IOAM domain might be cumbersome. I think tha= t there could be other methods to improve the security of the DEX option.
    • I can understand that the identity of a collector(s) of exported inf= ormation can be provisioned via the management or control plane. But I also= believe that there must be a discussion of why the Loopback option is not = a special case of the DEX option.
    Regards,
    Gr= eg

    On Sun, Nov 15, 2020 at 9:45 PM Martin Duke <martin.h.duke@gmail.com> wrote:<= br>
    I recognize that the loopback and direct export drafts discuss potential a= mplification results, as a path of length N will generate N packets for eac= h IOAM packet -- a linear relationship. As these are discussed in the draft= with proposed=C2=A0mitigation, in an editorial sense the job is done. Whet= her giving people this kind of foot gun is a good idea is a separate questi= on, but reasonable people can disagree.

    However, if I un= derstand correctly, certain pathological combinations of IOAM namespaces co= uld=C2=A0result in amplification far worse=C2=A0than linear.

    =
    1) Loopback loops
    Imagine there is an IOAM namespace t= hat covers the path from Hop A to Hop D. There is a separate namespace enti= rely contained in A-D, from hop B from hop C. Both namespaces enable loopba= ck.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A -----------------------------------= ---------------------D
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B-----------------------------= --C

    So a user packet is traveling from A to D. The= re will be (D-A) loopback packets headed towards A. The (D - C) loopback pa= ckets that generated between C and D will travel through the encapsulating= =C2=A0node at C and then trigger further loopbacks to C. Thus the total num= ber of packets generated by the single user packet is
    (D - A)=C2= =A0+ (D - C)(C - B)
    and obviousy there could be several of these = smaller namespaces, or nested namespaces, that aggravate the amplification = further.

    2) Direct Export
    Direct Export = potentially has even worse properties. Suppose namespace A, N_A hops across= , direct exports to a node that is reachable across namespace B. Namespace = B, N_B hops across, direct exports to a node reachable across namespace A.<= /div>

    Thus a single user packet sent over namespace A wi= ll generate N_A packets that traverse Namespace B. This will, in turn, gene= rate N_A * N_B packets that traverse namespace A, which in turn triggers N_= A ^ 2 * N_B packets, and so on.

    In fact, if the na= mespaces direct export with probability exactly,1/N_A and 1/N_B, the same l= evel of traffic will ping-pong infinitely. Any more than that, and the traf= fic will steadily increase to infinity. If the probability is 1, the growth= is exponential.

    ****************

    This analysis, if correct, raises three questions that I can think= of:
    - Are these corner cases plausible?
    - If so, and t= hey occurred, would the namespace administrators necessarily be aware of ea= ch other? If not, I'm concerned that this is unsafe to deploy.
    - Do phenomena like this indicate that the design is brittle and putting = in some "considerations" doesn't really mitigate the dangers = here?

    Martin




    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --0000000000001048c505b5ad4ae2-- From nobody Fri Dec 4 17:54:50 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E923A1187 for ; Fri, 4 Dec 2020 17:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LV1-9dARwsCO for ; Fri, 4 Dec 2020 17:54:45 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BEB83A1188 for ; Fri, 4 Dec 2020 17:54:44 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id z21so10234111lfe.12 for ; Fri, 04 Dec 2020 17:54:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jhed0osT1LBYFTUXAHEHBjDLJjHihEjBO7A3b7FpPNE=; b=Z4PAAfTW/Z0pZZsxEKsCg/e2puoFOkro3fn2QNII/n3tkri5ZLwDBiH2R37NygjgQo UNs2WdkwlzvOg+LSYn3YoYGQ0i9zpxKGkvTEB8AGBOC44dok9wzPGzgxKLK3NyNzRZGN kUoIq/Pu8E3ZbqIo3K78WRM2H0jP7Hl5N8HJzd1kjpabQPDnCkaYAz44R4VWF99cr2SK QJZ88KIirq5YXpI6MVLYv01UnWxjdhVImIzabeVexdVEm8BHso/tx1saxFnuJAIgdkEt 6ah1zm1GUPDfTTi/P6+oL+fwHSve7cUm5YeEvtorz7l061SEDg76o//tyo4bpvrb3lnV qBWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jhed0osT1LBYFTUXAHEHBjDLJjHihEjBO7A3b7FpPNE=; b=dAJeCjTkmn1IN5hPYn7lh24Xl77w/qS21mWtFJozTDU5I9nlJ61RhHSEXxccBu0wZn tFUh7vmKC/+Wf3wz6ZZd5g0ke1PKS9j1DSrJXyp81C9c2vvQSwdLiUDjQL5LWdie8/gZ 9gKlUNWxth1GjVfB89KWW3cCUZcQqaF3DjfiODgpjUZyVV8/BRlTwTTjn8/hV9gMJrin mTtI2FAyoGCRb66wHdAN4pjZx+X1BSDpr4XBHYJv8I19m9T12MgII62qtBnZXWXY/8Kx ccLx+EeqPtJTEt3CpgxvWPuLEFy555xp4/IyS4p/MAZjiQEQc55X7xrqc6JtT5m+0e7D I3ug== X-Gm-Message-State: AOAM532qzvJrrX3O4We6Q0zfSzeEZtYmCl1fv/ycpYpNYig4hgU89AC6 tFERlSHbswkyNTHHNMVOlH4YoikxDqvUv5tiEhQ= X-Google-Smtp-Source: ABdhPJyyv7mwXAFwrltq/8oi0TURRsyUOdjvj1PAUT8xTnp81W++DpvoVzKB+p+3LO9caUapSU5tYeWSDQBsXzJBh+g= X-Received: by 2002:a19:500a:: with SMTP id e10mr1182739lfb.193.1607133282860; Fri, 04 Dec 2020 17:54:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Fri, 4 Dec 2020 17:54:32 -0800 Message-ID: To: Martin Duke Cc: IETF IPPM WG , Greg Mirsky Content-Type: multipart/alternative; boundary="0000000000006e822905b5ade0b6" Archived-At: Subject: Re: [ippm] Is loopback/direct export amplification worse than linear? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 01:54:49 -0000 --0000000000006e822905b5ade0b6 Content-Type: text/plain; charset="UTF-8" Hi Martin, thank you for the clarification, I've missed that scenario. I'll need to look through all proposed IOAM encapsulations again. For some reason, I was assuming that the presence of IOAM in a data packet is always explicitly encoded and that can be used to differentiate between an IOAM and non-IOAM packet. Regards, Greg On Fri, Dec 4, 2020 at 5:12 PM Martin Duke wrote: > My argument is that it doesn't matter if the DEX is non-IOAM; the point is > if the signature of this packet happens to match the criteria on some other > IOAM domain, we end up in trouble. > > On Fri, Dec 4, 2020 at 4:53 PM Greg Mirsky wrote: > >> Hi Martin, >> I thought of them as "concerns" ;) >> I share your concerns regarding the impact of the Loopback flag. I think >> that if the returned packet travels back out-of-band, not as IOAM-esque >> packet that might mitigate some risks associated with the Loopback. And >> though I don't think that the DEX draft explicitly states that the IOAM >> data collected on a node is exported to a collector out-of-band, i.e., not >> as an IOAM packet, as well, I'd like the WG to consider this approach. >> The rest of my notes reflect my earlier comments. >> >> Regards, >> Greg >> >> On Fri, Dec 4, 2020 at 2:53 PM Martin Duke >> wrote: >> >>> thanks Greg. >>> >>> I hope I'm understanding you correctly these are critiques of the drafts >>> largely unrelated to mine? >>> >>> On Wed, Dec 2, 2020 at 3:06 PM Greg Mirsky >>> wrote: >>> >>>> Hi Martin, >>>> thank you for highlighting some troublesome characteristics of using >>>> the Loopback flag in IOAM. I agree that draft-ietf-ippm-ioam-flags could >>>> tighten up the description of scenarios when the Loopback flag is used. >>>> Also, it seems that the behavior of Direct Export >>>> can >>>> benefit from more clarifications. Now I've read both drafts taking notes >>>> and present them to you below: >>>> *draft-ietf-ippm-ioam-flags:* >>>> >>>> - draft-ietf-ippm-ioam-data defined IOAM as a method to record >>>> "operational and telemetry information in the packet while the packet >>>> traverses a path between two points in the network". It is an example of a >>>> hybrid measurement method, per RFC 7799 classification. The introduction of >>>> the Loopback and Active flags clearly makes IOAM into an active method and >>>> thus it should be discussed as a protocol that originates test packets, >>>> including potential security threats it may be used to create. >>>> - If the purpose of the Loopback flag is producing a series of >>>> responses from traversed nodes, then it might be much easier to use not a >>>> copy of the original packet but a different packet to respond to the sender >>>> (similar to CFM's LTM/LTR). That will avoid any risk of reverse-path >>>> amplification. >>>> - It is not clear what kind of path is expected in "a return path >>>> from transit nodes and destination nodes towards the source (encapsulating >>>> node) exists"? For example, if IOAM is used in an SFC environment, would >>>> Loopback require the use of an SFP to the sender? >>>> - It is not clear what establishes "the identity of the [IOAM] >>>> encapsulating node". Some examples would be helpful. >>>> - There seems to be a disconnect in handling unexpected looped IOAM >>>> packet: >>>> >>>> In the second paragraph Section 4 it is stated: >>>> "If an encapsulating node receives a looped back packet that was not >>>> originated from the current encapsulating node, the packet is dropped." >>>> >>>> But in the second from the last paragraph of the same section is noted >>>> that: >>>> "If there is no match in the Node ID, the packet is processed like a >>>> conventional IOAM-encapsulated packet." >>>> >>>> >>>> - The following probably may be expressed using the definitions >>>> from the IANA registry: >>>> >>>> An IOAM trace option that has the loopback bit set MUST have the >>>> value '1' in the most significant bit of IOAM-Trace-Type, and '0' in >>>> the rest of the bits of IOAM-Trace-Type. >>>> >>>> like that: >>>> An IOAM Trace Option that has the Loopback bit set MUST have the >>>> "hop_Lim and node_id in short format" bit set IOAM-Trace-Type, and >>>> MUST >>>> have all other bits of IOAM-Trace-Type cleared. >>>> >>>> >>>> - What is the value of collecting "hop_Lim and node_id in short >>>> format" on the return path of a packet looped back by an intermediate node? >>>> As I understand it, only that information can be collected if the Loopback >>>> flag is set. Please correct me if that is not the case. >>>> - Can you point where it is specified that when using the Loopback >>>> "the packet does not have any payload"? Earlier in Section 4 action of an >>>> intermediate node is explained: >>>> >>>> A loopback bit that is set indicates to the transit nodes processing >>>> this option that they are to create a copy of the received packet and >>>> send the copy back to the source of the packet. >>>> >>>> One can understand that the looped back packet is a carbon copy of the >>>> original packet less the Loopback flag being cleared. And the actions of >>>> the encapsulating node are described as: >>>> The encapsulating node either generates synthetic packets with an >>>> IOAM trace option that has the loopback flag set, or sets the loopack >>>> flag in a subset of the in-transit data packets. >>>> >>>> Which suggests that, at least in the latter case, the packet with the >>>> Loopback flag set does have a payload. >>>> >>>> >>>> - One of the essential aspects of defining an active measurement >>>> protocol is the specification of the expected rates that test packets be >>>> generated for the intended purpose of the protocol. Some protocols provide >>>> a mechanism to negotiate that rate either through its control-plane >>>> component or as part of bringing the test session to Up state. I couldn't >>>> find any discussion of the expected purpose of using the Active flag, nor >>>> sufficient information that would help to set reasonable limits on >>>> processing packets with the Active flag set. Also, even though the document >>>> is on the Standards track, I find normative language in relation to the >>>> security impact of Loopback and Active flags being underused. >>>> - Applying rate limits throughout the IOAM domain might be >>>> cumbersome. I think that stronger security methods must be defined making >>>> using the Loopback and Active options more secure. For example, using >>>> authentication to ensure the identity of the encapsulating IOAM node that >>>> imposed the Loopback or Active option. >>>> >>>> *draft-ietf-ippm-ioam-direct-export* >>>> >>>> - Section 3.1 includes very important assumption: >>>> >>>> The option [DEX] can be read but not modified by transit nodes. >>>> >>>> That brings the question What protects the DEX option in particular and >>>> IOAM-Option-Types in general? >>>> >>>> >>>> - The description of the processing of the DEX option by >>>> encapsulating, transit, and decapsulating nodes in an IOAM domain in all >>>> cases states "MAY export the requested IOAM data". What are other possible >>>> behaviors of nodes processing the DEX option? >>>> - In the last paragraph of Section 3.1 stated: >>>> >>>> A transit IOAM node that does not support the DEX option SHOULD >>>> ignore it. >>>> >>>> What are other allowed behaviors of a node, whether transit or >>>> decapsulating? Report an error? Discard the packet with the DEX option? >>>> >>>> >>>> - Though considerations for performance impact at a collector(s) is >>>> sensible, it seems that the impact on the node exporting telemetry >>>> information triggered by the DEX should also be considered. >>>> - Applying rate limits throughout the IOAM domain might be >>>> cumbersome. I think that there could be other methods to improve the >>>> security of the DEX option. >>>> - I can understand that the identity of a collector(s) of exported >>>> information can be provisioned via the management or control plane. But I >>>> also believe that there must be a discussion of why the Loopback option is >>>> not a special case of the DEX option. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Sun, Nov 15, 2020 at 9:45 PM Martin Duke >>>> wrote: >>>> >>>>> I recognize that the loopback and direct export drafts discuss >>>>> potential amplification results, as a path of length N will generate N >>>>> packets for each IOAM packet -- a linear relationship. As these are >>>>> discussed in the draft with proposed mitigation, in an editorial sense the >>>>> job is done. Whether giving people this kind of foot gun is a good idea is >>>>> a separate question, but reasonable people can disagree. >>>>> >>>>> However, if I understand correctly, certain pathological combinations >>>>> of IOAM namespaces could result in amplification far worse than linear. >>>>> >>>>> 1) Loopback loops >>>>> Imagine there is an IOAM namespace that covers the path from Hop A to >>>>> Hop D. There is a separate namespace entirely contained in A-D, from hop B >>>>> from hop C. Both namespaces enable loopback. >>>>> A >>>>> --------------------------------------------------------D >>>>> >>>>> B-------------------------------C >>>>> >>>>> So a user packet is traveling from A to D. There will be (D-A) >>>>> loopback packets headed towards A. The (D - C) loopback packets that >>>>> generated between C and D will travel through the encapsulating node at C >>>>> and then trigger further loopbacks to C. Thus the total number of packets >>>>> generated by the single user packet is >>>>> (D - A) + (D - C)(C - B) >>>>> and obviousy there could be several of these smaller namespaces, or >>>>> nested namespaces, that aggravate the amplification further. >>>>> >>>>> 2) Direct Export >>>>> Direct Export potentially has even worse properties. Suppose namespace >>>>> A, N_A hops across, direct exports to a node that is reachable across >>>>> namespace B. Namespace B, N_B hops across, direct exports to a node >>>>> reachable across namespace A. >>>>> >>>>> Thus a single user packet sent over namespace A will generate N_A >>>>> packets that traverse Namespace B. This will, in turn, generate N_A * N_B >>>>> packets that traverse namespace A, which in turn triggers N_A ^ 2 * N_B >>>>> packets, and so on. >>>>> >>>>> In fact, if the namespaces direct export with probability >>>>> exactly,1/N_A and 1/N_B, the same level of traffic will ping-pong >>>>> infinitely. Any more than that, and the traffic will steadily increase to >>>>> infinity. If the probability is 1, the growth is exponential. >>>>> >>>>> **************** >>>>> >>>>> This analysis, if correct, raises three questions that I can think of: >>>>> - Are these corner cases plausible? >>>>> - If so, and they occurred, would the namespace administrators >>>>> necessarily be aware of each other? If not, I'm concerned that this is >>>>> unsafe to deploy. >>>>> - Do phenomena like this indicate that the design is brittle and >>>>> putting in some "considerations" doesn't really mitigate the dangers here? >>>>> >>>>> Martin >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> ippm mailing list >>>>> ippm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ippm >>>>> >>>> --0000000000006e822905b5ade0b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Martin,
    thank you for the clarification, I've m= issed that scenario. I'll need to look through all proposed IOAM encaps= ulations again. For some reason, I was assuming that the presence of IOAM i= n a data packet is always explicitly=20 encoded=20 and that can be used to differentiate between an IOAM and non-IOAM packet.<= /div>

    Regards,
    Greg

    On Fri, Dec 4, 2020 = at 5:12 PM Martin Duke <marti= n.h.duke@gmail.com> wrote:
    My argument is that it doesn't matte= r if the DEX is non-IOAM; the point is if the signature of this packet happ= ens to match the criteria on some other IOAM domain, we end up in trouble.<= /div>
    O= n Fri, Dec 4, 2020 at 4:53 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
    Hi Mart= in,
    I thought of them as "concerns" ;)
    I share your= concerns=C2=A0regarding the impact of the Loopback flag. I think that if t= he returned packet travels back out-of-band, not as IOAM-esque packet that = might mitigate some risks associated with the Loopback. And though I don= 9;t think that the DEX draft explicitly states that the IOAM data collected= on a node is exported to a collector out-of-band, i.e., not as an IOAM pac= ket, as well, I'd like the WG to consider this approach.
    The = rest of my notes reflect my earlier=C2=A0comments.

    Regards,
    Greg

    On Fri, Dec 4, 2020 at 2:53 PM Martin Duke &l= t;martin.h.duk= e@gmail.com> wrote:
    thanks Greg.

    I hope I'm = understanding you correctly these are critiques of the drafts largely unrel= ated=C2=A0to mine?

    On Wed, Dec 2, 2020 at 3:06 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:
    Hi Martin,
    thank you for highlighting some troublesom= e characteristics of using the Loopback flag in IOAM. I agree that=C2=A0dra= ft-ietf-ippm-ioam-flags could tighten up the description of scenarios when = the Loopback flag is used. Also, it seems that the behavior of=C2=A0Direct Export=C2=A0can benefit from m= ore clarifications. Now I've read both drafts taking notes and present = them to you below:
    draft-ietf-ippm-ioam-flags:
    <= ul>
  • draft-ietf-ippm-ioam-data defined IOAM as a method to record "o= perational and telemetry information in the packet while the packet travers= es a path between two points in the network". It is an example of a hy= brid measurement method, per RFC 7799 classification. The introduction of t= he Loopback and Active flags clearly makes IOAM into an active method and t= hus it should be discussed as a protocol that originates test packets, incl= uding potential security threats it may be used to create.
  • If t= he purpose of the Loopback flag is producing a series of responses=C2=A0fro= m traversed nodes, then it might be much easier to use not a copy of the or= iginal packet but a different packet to respond to the sender (similar to C= FM's LTM/LTR). That will avoid any risk of reverse-path amplification.<= /li>
  • It is not clear what kind of path is expected in "a return pat= h from transit nodes and destination nodes towards the source (encapsulatin= g node) exists"? For example, if IOAM is used in an SFC environment, w= ould Loopback require the use of an SFP to the sender?
  • It is not cl= ear what establishes "the identity of the [IOAM] encapsulating node&qu= ot;. Some examples would be helpful.
  • There seems to be a disconnect= in handling unexpected looped IOAM packet:
    • In the second paragrap= h Section 4 it is stated:
    "If an encapsulating node receives= a looped back packet that was not originated from the current encapsulatin= g node, the packet is dropped."
    But in the second fr= om the last paragraph of the same section is noted that:
    "If= there is no match in the Node ID, the packet is processed like a conventio= nal IOAM-encapsulated packet."
    • The following= probably may be expressed using the definitions from the IANA registry:
    like that:
    =C2=A0 =C2=A0A= n IOAM Trace Option that has the Loopback bit set MUST have the
    =C2=A0 = =C2=A0"hop_Lim and node_id in short format" bit set IOAM-Trace-Ty= pe, and MUST=C2=A0
    =C2=A0 =C2=A0have all other bits of IOAM-Trace= -Type cleared.
    • What is the value of collectin= g "hop_Lim and node_id in short format" on the return path of a p= acket looped back by an intermediate node? As I understand it, only that in= formation can be collected if the Loopback flag is set. Please correct me i= f that is not the case.
    • Can you point where it is specified that wh= en using the Loopback "the packet does not have any payload"? Ear= lier in Section 4 action of an intermediate node is explained:
    =C2= =A0 =C2=A0A loopback bit that is set indicates to the transit nodes process= ing
    =C2=A0 =C2=A0this option that they are to create a copy of the recei= ved packet and
    =C2=A0 =C2=A0send the copy back to the source of the pack= et.
    One can understand that the looped back packet is= a carbon copy of the original packet less the Loopback flag being cleared.= And the actions of the encapsulating node are described as:
    =C2= =A0 =C2=A0The encapsulating node either generates synthetic packets with an=
    =C2=A0 =C2=A0IOAM trace option that has the loopback flag set, or sets = the loopack
    =C2=A0 =C2=A0flag in a subset of the in-transit data packets= .
    Which suggests that, at least in the latter case, t= he packet with the Loopback flag set does have a payload.
    • One of the essential aspects of defining an active measurement pro= tocol is the specification of the expected rates that test packets be gener= ated for the intended purpose of the protocol. Some protocols provide a mec= hanism to negotiate that rate either through its control-plane component or= as part of bringing the test session to Up state. I couldn't find any = discussion of the expected purpose of using the Active flag, nor sufficient= information that would help to set reasonable limits on processing packets= with the Active flag set. Also, even though the document is on the Standar= ds track, I find normative language in relation to the security impact of L= oopback and Active flags being underused.
    • Applying rate limits thro= ughout the IOAM domain might be cumbersome. I think that stronger security = methods must be defined making using=C2=A0the Loopback and Active options m= ore secure. For example, using authentication to ensure the identity of the= encapsulating IOAM node that imposed the Loopback or Active option.
    draft-ietf-ippm-ioam-direct-export
    • Sect= ion 3.1 includes very important assumption:
    =C2=A0 The option [DEX= ] can be read but not modified by transit nodes.
    That= brings the question What protects the DEX option in particular and IOAM-Op= tion-Types in general?
    • The description of the pro= cessing of the DEX option by encapsulating, transit, and decapsulating node= s in an IOAM domain in all cases states "MAY export the requested IOAM= data". What are other possible behaviors of nodes processing the DEX = option?
    • In the last paragraph=C2=A0of Section 3.1 stated:
    =
    = =C2=A0 A transit IOAM node that does not support the DEX option SHOULD igno= re it.
    What are other allowed behaviors of a node, wh= ether transit or decapsulating? Report=C2=A0an error? Discard the packet wi= th the DEX option?
    • Though considerations for=C2= =A0performance impact at=C2=A0a collector(s) is sensible, it seems that the= impact on the node exporting telemetry information triggered by the DEX sh= ould also be considered.
    • Applying rate limits throughout the IOAM d= omain might be cumbersome. I think that there could be other methods to imp= rove the security of the DEX option.
    • I can understand that the iden= tity of a collector(s) of exported information can be provisioned via the m= anagement or control plane. But I also believe that there must be a discuss= ion of why the Loopback option is not a special case of the DEX option.
    Regards,
    Greg

    On Sun, Nov 15, 2020 at 9:45 PM Mar= tin Duke <m= artin.h.duke@gmail.com> wrote:
    I recognize that the loopback and di= rect export drafts discuss potential amplification results, as a path of le= ngth N will generate N packets for each IOAM packet -- a linear relationshi= p. As these are discussed in the draft with proposed=C2=A0mitigation, in an= editorial sense the job is done. Whether giving people this kind of foot g= un is a good idea is a separate question, but reasonable people can disagre= e.

    However, if I understand correctly, certain pathologi= cal combinations of IOAM namespaces could=C2=A0result in amplification far = worse=C2=A0than linear.

    1) Loopback loops
    Imagine there is an IOAM namespace that covers the path from Hop A to Hop= D. There is a separate namespace entirely contained in A-D, from hop B fro= m hop C. Both namespaces enable loopback.
    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0A --------------------------------------------------------D
    = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0B-------------------------------C

    So = a user packet is traveling from A to D. There will be (D-A) loopback packet= s headed towards A. The (D - C) loopback packets that generated between C a= nd D will travel through the encapsulating=C2=A0node at C and then trigger = further loopbacks to C. Thus the total number of packets generated by the s= ingle user packet is
    (D - A)=C2=A0+ (D - C)(C - B)
    and = obviousy there could be several of these smaller namespaces, or nested name= spaces, that aggravate the amplification further.

    = 2) Direct Export
    Direct Export potentially has even worse propert= ies. Suppose namespace A, N_A hops across, direct exports to a node that is= reachable across namespace B. Namespace B, N_B hops across, direct exports= to a node reachable across namespace A.

    Thus a si= ngle user packet sent over namespace A will generate N_A packets that trave= rse Namespace B. This will, in turn, generate N_A * N_B packets that traver= se namespace A, which in turn triggers N_A ^ 2 * N_B packets, and so on.

    In fact, if the namespaces direct export with probab= ility exactly,1/N_A and 1/N_B, the same level of traffic will ping-pong inf= initely. Any more than that, and the traffic will steadily increase to infi= nity. If the probability is 1, the growth is exponential.

    ****************

    This analysis, if correct= , raises three questions that I can think of:
    - Are these corner = cases plausible?
    - If so, and they occurred, would the namespace = administrators necessarily be aware of each other? If not, I'm concerne= d that this is unsafe to deploy.
    - Do phenomena like this indicat= e that the design is brittle and putting in some "considerations"= doesn't really mitigate the dangers here?

    Mar= tin




    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --0000000000006e822905b5ade0b6-- From nobody Fri Dec 4 19:29:25 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7473A0829; Fri, 4 Dec 2020 19:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, HTML_MESSAGE=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 (2048-bit key) header.d=apple.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 7Vd06_tyIXj6; Fri, 4 Dec 2020 19:29:22 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 92B273A0825; Fri, 4 Dec 2020 19:29:22 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0B53NxX7012259; Fri, 4 Dec 2020 19:29:21 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=nzajiM2hPhILmlGEREQIqwYy9wD1OO/Uzdnrx2lIDGI=; b=gc0OPoXlLcV8lPzDdnYAu47V23/a2LYaewKFQ8J3ycK9/78cGLBZb0E4pxPh7U6vVZzc IgVIm8/GIz0LEMYfIXKTALdkzjTGwkaouowl/mbb2glr4pHROoHULBuO3JDJR0JXzSan CJKqvJeppRcRq5QcaWfLEdk6FDkzkXGWkLIwUPakr9KLPMFMX4fwOyvWeBH5UErNFSIZ ylNjLoItDLvGmhHjf4FZWNKUTqKqLjcKYUYTMDkZBeprD8SQOJw3aCUgsKcYlqJBRorD Ws//F+Am2cj4kFSS7CQFPfHQKh5NScAtFFPeWK1aRhBQt64/PKM62giFk66vTq8IoIXf pA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 353p393nwc-19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 04 Dec 2020 19:29:21 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QKU002OEKCX4YB0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Fri, 04 Dec 2020 19:29:21 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QKU00800JL6ZZ00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 04 Dec 2020 19:29:21 -0800 (PST) X-Va-A: X-Va-T-CD: de279c0840622e930446fe69a11c94de X-Va-E-CD: bb7955093777dbac45275c623dc60aef X-Va-R-CD: 9f130a3872e01aa196c3a1d21f031c66 X-Va-CD: 0 X-Va-ID: ea4f7d54-787b-4c9f-9a17-b410571debc9 X-V-A: X-V-T-CD: de279c0840622e930446fe69a11c94de X-V-E-CD: bb7955093777dbac45275c623dc60aef X-V-R-CD: 9f130a3872e01aa196c3a1d21f031c66 X-V-CD: 0 X-V-ID: e8425b40-fb05-40e9-939b-5ac564637be5 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-05_01:2020-12-04, 2020-12-05 signatures=0 Received: from localhost.localdomain (unknown [17.232.205.131]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QKU00WGCKCN9Z00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 04 Dec 2020 19:29:12 -0800 (PST) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_16213A67-96D4-4397-862A-4739DF21BEAF" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Date: Fri, 04 Dec 2020 19:29:11 -0800 In-reply-to: Cc: IPPM Chairs , spring-chairs@ietf.org To: "IETF IPPM WG (ippm@ietf.org)" References: X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-05_01:2020-12-04, 2020-12-05 signatures=0 Archived-At: Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 03:29:25 -0000 --Apple-Mail=_16213A67-96D4-4397-862A-4739DF21BEAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello IPPM, Thanks to everyone who provided feedback on these documents. Your time = and consideration are much appreciated. Two things are clear from the feedback, in the chairs=E2=80=99 = perspective: - There was a lot of interest expressed on the list for ensuring that = work is done to support the work in SPRING - There are relevant concerns being raised about the manner in which = these documents propose extending TWAMP Light and STAMP, particularly = with regards to duplicating existing capabilities in ways that choose to = optimize differently=20 Given that, we do not believe that the drafts in their current form are = ready to be adopted by IPPM. We still believe that it is correct for the = work in SPRING to reference IPPM work rather than define extensions to = these protocols there, but the specifics of the work in IPPM needs to be = further refined. We=E2=80=99ll discuss further steps with the authors of the document. Thanks again to all, for working together to come to the best unified = solutions. Best, Tommy & Ian > On Oct 30, 2020, at 11:34 AM, Tommy Pauly = wrote: >=20 > Hello IPPM, >=20 > For the past few meetings, we=E2=80=99ve had updates on the work in = the SPRING WG that was using STAMP and TWAMP. Since those documents = ended up making extensions to the base protocols, the chairs of SPRING = and IPPM decided that it would be best to split the documents and track = the IPPM extension work in the IPPM WG. >=20 > As such, we are starting a Working Group call for adoption for = draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm. >=20 > The documents are here: >=20 > https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 = > https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 = >=20 > The related SPRING documents are here: >=20 > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 = > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 = >=20 > Please provide your feedback on these documents, and state whether or = not you believe the IPPM WG should adopt this work by replying to this = email. Please provide your feedback by the start of the IETF 109 meeting = week, on Monday, November 16. >=20 > Best, > Tommy & Ian > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_16213A67-96D4-4397-862A-4739DF21BEAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= IPPM,

    Thanks to = everyone who provided feedback on these documents. Your time and = consideration are much appreciated.

    Two things are clear from the feedback, = in the chairs=E2=80=99 perspective:
    - There was a = lot of interest expressed on the list for ensuring that work is done to = support the work in SPRING
    - There are relevant = concerns being raised about the manner in which these documents propose = extending TWAMP Light and STAMP, particularly with regards to = duplicating existing capabilities in ways that choose to optimize = differently 

    Given that, we do not believe that the drafts in their = current form are ready to be adopted by IPPM. We still believe that it = is correct for the work in SPRING to reference IPPM work rather than = define extensions to these protocols there, but the specifics of the = work in IPPM needs to be further refined.

    We=E2=80=99ll discuss further steps = with the authors of the document.

    Thanks again to all, for working = together to come to the best unified solutions.

    Best,
    Tommy & = Ian


    On Oct 30, 2020, at 11:34 AM, = Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

    Hello = IPPM,

    For the = past few meetings, we=E2=80=99ve had updates on the work in the SPRING = WG that was using STAMP and TWAMP. Since those documents ended up making = extensions to the base protocols, the chairs of SPRING and IPPM decided = that it would be best to split the documents and track the IPPM = extension work in the IPPM WG.

    As such, we are starting a Working = Group call for adoption for draft-gandhi-ippm-twamp-srpm and = draft-gandhi-ippm-stamp-srpm.

    The documents are here:

    https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00=
    https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00=

    The related SPRING documents are here:

    https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03
    https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11


    Tommy & = Ian
    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm

    = --Apple-Mail=_16213A67-96D4-4397-862A-4739DF21BEAF-- From nobody Fri Dec 4 19:34:58 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB91B3A083F; Fri, 4 Dec 2020 19:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, HTML_MESSAGE=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 (2048-bit key) header.d=apple.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 US-CWwxdEI3i; Fri, 4 Dec 2020 19:34:55 -0800 (PST) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.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 269043A083E; Fri, 4 Dec 2020 19:34:55 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.43/8.16.0.42) with SMTP id 0B53UhwF064802; Fri, 4 Dec 2020 19:34:54 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=2rjIMaZXL8OeFEqeuukwUDX0n/kS0KM7+kd3EuyKI58=; b=gC1/pxymG88Ip3TYc3rDtKcK+EZzCNOB5MAU6aviamgRVkC+zTGAgb5uguvZ9eMLQb/Y Mz9j55ijqV+N+TVs+czgHQV5oyYpbKjTFgo7McgaS/5LMBUSpgZ1m6/SKX4fHovbFFLT xzQrQeB0aq3HyOPtonyAPWB42dpiXNG5l66CF9NSiFwrASfpSwvGjZGegPhUuHYGpj9n /EZPpv8uPvoxZ6Q7NXbnhkrXG/qiquF9eJhEjkj1cLF2zTn3Ee+/rw22tMVI8VQuKCOd PoK2Zkts5FfOKLHZQUoDHM+5hHghutAvEyDQ0L6ywXro2lcMAku5zUxRhoePcyJmxBTF jQ== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by nwk-aaemail-lapp02.apple.com with ESMTP id 353m0pxu2d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 04 Dec 2020 19:34:54 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QKU001KZKM6RE50@rn-mailsvcp-mta-lapp03.rno.apple.com>; Fri, 04 Dec 2020 19:34:54 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QKU00800JL6ZZ00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 04 Dec 2020 19:34:54 -0800 (PST) X-Va-A: X-Va-T-CD: de279c0840622e930446fe69a11c94de X-Va-E-CD: aa33c189dbd445e6fb794f81e6318e9f X-Va-R-CD: 91f0815d8c33ca09afc5a8bd37f2bf91 X-Va-CD: 0 X-Va-ID: 25eb329a-a6d5-4d06-8a68-7d461e447424 X-V-A: X-V-T-CD: de279c0840622e930446fe69a11c94de X-V-E-CD: aa33c189dbd445e6fb794f81e6318e9f X-V-R-CD: 91f0815d8c33ca09afc5a8bd37f2bf91 X-V-CD: 0 X-V-ID: 1f6425bb-a299-4384-ae90-cd9c874fe5f8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-05_01:2020-12-04, 2020-12-05 signatures=0 Received: from localhost.localdomain (unknown [17.232.205.131]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QKU00KDHKLXV800@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 04 Dec 2020 19:34:45 -0800 (PST) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_4B21A974-374C-44DA-BEB4-1E3AFDF8F079" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Date: Fri, 04 Dec 2020 19:34:45 -0800 In-reply-to: <43DADFB5-FE8A-49A1-BF39-1ECC10594211@apple.com> Cc: IPPM Chairs To: "IETF IPPM WG (ippm@ietf.org)" References: <43DADFB5-FE8A-49A1-BF39-1ECC10594211@apple.com> X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-05_01:2020-12-04, 2020-12-05 signatures=0 Archived-At: Subject: Re: [ippm] Call for adoption: draft-zhou-ippm-ioam-yang X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 03:34:57 -0000 --Apple-Mail=_4B21A974-374C-44DA-BEB4-1E3AFDF8F079 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello IPPM, Thanks to everyone who provided feedback! The chairs believe there is = consensus to adopt draft-zhou-ippm-ioam-yang, and we will be adopting it = as a working group. Some valuable feedback about refinements and enhancements to the = document were made during the call, and we would ask the authors to = incorporate as much as possible before submitting the = draft-ietc-ippm-ioam-yang-00 version. Best, Tommy & Ian > On Oct 30, 2020, at 11:40 AM, Tommy Pauly wrote: >=20 > Hello IPPM, >=20 > This email starts a Working Group call for adoption for = draft-zhou-ippm-ioam-yang. Now that our IOAM documents are mature and = progressing, the chairs believe it is time to consider the YANG work = officially. >=20 > The document can be found here: >=20 > https://tools.ietf.org/html/draft-zhou-ippm-ioam-yang-08 = >=20 > Please provide your feedback on these document, and state whether or = not you believe the IPPM WG should adopt this work by replying to this = email. Please provide your feedback by the start of the IETF 109 meeting = week, on Monday, November 16. >=20 > Best, > Tommy & Ian --Apple-Mail=_4B21A974-374C-44DA-BEB4-1E3AFDF8F079 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello= IPPM,

    Thanks to = everyone who provided feedback! The chairs believe there is consensus to = adopt draft-zhou-ippm-ioam-yang, and we will be adopting it as a working = group.

    Some = valuable feedback about refinements and enhancements to the document = were made during the call, and we would ask the authors to incorporate = as much as possible before submitting the draft-ietc-ippm-ioam-yang-00 version.

    Best,
    Tommy = & Ian

    On Oct = 30, 2020, at 11:40 AM, Tommy Pauly <tpauly@apple.com> wrote:

    Hello = IPPM,

    This email starts a Working = Group call for adoption for draft-zhou-ippm-ioam-yang. Now that our = IOAM documents are mature and progressing, the chairs believe it is time = to consider the YANG work officially.

    The = document can be found here:

    https://tools.ietf.org/html/draft-zhou-ippm-ioam-yang-08
    Please provide your feedback on these = document, and state whether or not you believe the IPPM WG should adopt = this work by replying to this email. Please provide your feedback by the = start of the IETF 109 meeting week, on Monday, = November 16.

    Best,
    Tommy = & Ian

    = --Apple-Mail=_4B21A974-374C-44DA-BEB4-1E3AFDF8F079-- From nobody Fri Dec 4 20:04:25 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850CD3A0992; Fri, 4 Dec 2020 20:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, HTML_MESSAGE=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 (2048-bit key) header.d=apple.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 V6iGT7ivw-4c; Fri, 4 Dec 2020 20:04:22 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 C3DB43A098A; Fri, 4 Dec 2020 20:04:21 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0B53vwjG002175; Fri, 4 Dec 2020 20:04:20 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=k8n3J89nVdSa2UXEHC9EjqA2aQeVEjW6ot7T7LAQj9M=; b=LL+Pw6u9Xz1gyXcueSbGkHC6MRmbYQbySnxuIjgi2pe+BOdJZ470yM4/YPIJaWcXVkmg G8oIyJUl8AUczbMqm7b4eBmH89/fAqaYZ5CazUpsbWXOrOY6hgA5BBo/MrCemQYVgmm9 L3yM290xnkTS0cmOGxj5RlQMY0laLlR+M0sdzzPy2DZK+2kwiKEP8xNyFnfmnC6b1Nl9 dqzuW1llh5CZlMOHh3guBpDZ4/fwTLEFtuon4qjcUC+lWPcv/65PWrCKlBcz0DppM19V kLK9WvoPrir4VMJvDGiW6rbVPtnLFWACG2uAQXdq/TMVq3G4ARM7HEmidCGs1/VSuztT ww== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 353p3941w8-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 04 Dec 2020 20:04:20 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QKU010IULZ7FN50@rn-mailsvcp-mta-lapp04.rno.apple.com>; Fri, 04 Dec 2020 20:04:19 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QKU00Z00LSCY200@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 04 Dec 2020 20:04:19 -0800 (PST) X-Va-A: X-Va-T-CD: de279c0840622e930446fe69a11c94de X-Va-E-CD: 7502921198a6e94a306d2cf689925042 X-Va-R-CD: 74999a51a99a186f1dee501ac6f25f77 X-Va-CD: 0 X-Va-ID: 05e26397-b273-4d48-af40-53f83c72a50f X-V-A: X-V-T-CD: de279c0840622e930446fe69a11c94de X-V-E-CD: 7502921198a6e94a306d2cf689925042 X-V-R-CD: 74999a51a99a186f1dee501ac6f25f77 X-V-CD: 0 X-V-ID: 103acb04-d153-4b6e-bf5d-cc27e58c5d30 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-05_02:2020-12-04, 2020-12-05 signatures=0 Received: from localhost.localdomain (unknown [17.232.205.131]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QKU00ZLNLZ47500@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 04 Dec 2020 20:04:17 -0800 (PST) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_EDBA7A47-0864-45D7-A5F4-8D7C88FE2A9C" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Date: Fri, 04 Dec 2020 20:04:16 -0800 In-reply-to: <63A1B18E-A7F6-4F91-8503-F1FCE3CF945A@apple.com> Cc: IPPM Chairs To: "IETF IPPM WG (ippm@ietf.org)" References: <63A1B18E-A7F6-4F91-8503-F1FCE3CF945A@apple.com> X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-05_02:2020-12-04, 2020-12-05 signatures=0 Archived-At: Subject: Re: [ippm] Call for adoption: draft-geib-ippm-connectivity-monitoring X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 04:04:24 -0000 --Apple-Mail=_EDBA7A47-0864-45D7-A5F4-8D7C88FE2A9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello IPPM, Thanks for the feedback on this document. While we did not receive many = pieces feedback, the feedback we did receive was positive and had = substantive reviews. As such, the chairs believe this document is ready = to be adopted. Ruediger, please prepare a new version that incorporates the feedback = received, and submit as draft-ietf-ippm-connectivity-monitoring-00. Best, Tommy & Ian > On Oct 30, 2020, at 11:43 AM, Tommy Pauly = wrote: >=20 > Hello IPPM, >=20 > This email starts a Working Group call for adoption for = draft-geib-ippm-connectivity-monitoring. This document has been = presented several times and discussed within the working group. >=20 > The document can be found here: >=20 > https://tools.ietf.org/html/draft-geib-ippm-connectivity-monitoring-03 = >=20 > Please provide your feedback on these document, and state whether or = not you believe the IPPM WG should adopt this work by replying to this = email. Please provide your feedback by the start of the IETF 109 meeting = week, on Monday, November 16. >=20 > Best, > Tommy & Ian > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_EDBA7A47-0864-45D7-A5F4-8D7C88FE2A9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello= IPPM,

    Thanks for = the feedback on this document. While we did not receive many pieces = feedback, the feedback we did receive was positive and had substantive = reviews. As such, the chairs believe this document is ready to be = adopted.

    Ruediger, please prepare a new version that incorporates the = feedback received, and submit = as draft-ietf-ippm-connectivity-monitoring-00.

    Best,
    Tommy & Ian

    On Oct = 30, 2020, at 11:43 AM, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

    Hello = IPPM,

    This email starts a Working = Group call for adoption = for draft-geib-ippm-connectivity-monitoring. This document has been = presented several times and discussed within the working group.

    The document can be found here:

    https://tools.ietf.org/html/draft-geib-ippm-connectivity-monito= ring-03

    Please provide your feedback on = these document, and state whether or not you believe the IPPM WG should = adopt this work by replying to this email. Please provide your feedback = by the start of the IETF 109 meeting week, on Monday, November 16.

    Best,
    Tommy & = Ian
    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm

    = --Apple-Mail=_EDBA7A47-0864-45D7-A5F4-8D7C88FE2A9C-- From nobody Fri Dec 4 22:15:49 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531EF3A0CDA; Fri, 4 Dec 2020 22:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 yI6suHXHupnB; Fri, 4 Dec 2020 22:15:33 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC613A0C97; Fri, 4 Dec 2020 22:15:32 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id t8so5301291pfg.8; Fri, 04 Dec 2020 22:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qNMTBUtlj473GnPIKbbbdNt9isAQENx9rJ6k8ECId1I=; b=VTi/PAqfP5FomJWWYim7w4MwyHgo3NUvC2A5xJjPOUA3ZtJF62hmDZ2bvxZJ19EsM0 t2sxFlBoSs+Fp10hh4ultmuyXxygayor8zoGBGc85xM5X+oOQw+A9czWLo3NpHr+RlAh uL4TG26H61L9Ho5cTK1RHToHUXybK1HIkwpadWEISnfwhgTzT0to7iJjEPSzDZq1oy6h imO1c3gLN3Vlk87JT5JSPcIGZPMFbYkc5lh5tb5F52tC4K597DRDdohNdb2lyCu4tOjW /jM4rw4IACAkcTKwTHIT5BhnP7gsnC7RfHwzNpymYFJzGyNhIZxXYylzrjwyQ8YCuIGH mksw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qNMTBUtlj473GnPIKbbbdNt9isAQENx9rJ6k8ECId1I=; b=saiSfCSS/KHDatSB+mo9HFJu9mFAfDCEyDsM9P5y77P7RW6hBcjkT7IzSGbQ2Clnab Y5odSHDj20v9MlOssd33kP6utwQX0CmtKjiibAW3C6yRTFfG4oV/V2jp+UeJJacGj+0F ihQzCcE2ypvkB9S0ZhH2cxTUGcLb/GC7FsPVR4yVyj72KwO2N9aquxcp6wJIjcemLjyD ktL62cj6SC4JEHMotrSQ6xtYsvf4oV0sLbR6C3vK56LShM0lfQf+UPh64yap3YfFfNqd IJtcWQ3EhwEN3X/+HLTDqwd5p3vaRuTMCHVVlu6idqOCuI/mW7/116uRtvCAf9yhDGNI kn/Q== X-Gm-Message-State: AOAM532wCTj5rgfU719G/FQ11wR+z21STeaJxgHaf4iaU++X7XZVwAUa lLMoZmkf7fsyKrMF3upxcc2aYIF0zC2yPL8A8KE= X-Google-Smtp-Source: ABdhPJwi+Fyhrzrl+zHXGlpsys1m3UtoJ/ZBo16DYMjmNbfqs//r5WN8+7BqrqLjT29sEkaJP+gipuv61RaiaHR3BrM= X-Received: by 2002:a65:5ac4:: with SMTP id d4mr1401292pgt.50.1607148931762; Fri, 04 Dec 2020 22:15:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sat, 5 Dec 2020 01:15:20 -0500 Message-ID: To: Greg Mirsky Cc: Greg Mirsky , IETF IPPM WG , James Guichard , "Rakesh Gandhi (rgandhi)" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002dce6a05b5b185f9" Archived-At: Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 06:15:43 -0000 --0000000000002dce6a05b5b185f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rakesh Had a general question. I read through the draft again and a question came to mind as this draft is Standards Track, what new is being introduced other then a procedure of how to use TWAMP in SR networks SR-MPLS which reuses the MPLS data plane and SRv6 which used the IPv6 data plane. I don=E2=80=99t believe there exists = a Standards track draft procedure for how to use STAMP over IP network or MPLS network as an example. Section 4.1.4 describes SR-MPLS use case and SRv6 use case. As there appears to be nothing new introduced such as a new IANA TLV or code point or even a special SID code point for TWAMP, all basic vanilla SR, that without this draft you could run STAMP, TWAMP, OWAMP over SR which has existed for a while now. What is the new invention here? Sorry but I may have missed something. My thoughts are at most this be a BCP or I am thinking informational draft would be appropriate. Thoughts? Gyan On Thu, Dec 3, 2020 at 12:51 PM Greg Mirsky wrote: > Hi Rakesh, > thank you for the continued discussion. You can find my follow-up notes > in-line below under GIM3>> tag. I felt that one comment is at the root of > our different views on what is considered to be a problem that drafts > solve. You've said: > > As mentioned, the extensions defined are for the direct-mode packet > loss measurement for TWAMP Light and STAMP. > > But draft-ietf-ippm-stamp-option-tlv > , > currently in Submitted to IESG for Publication WG state according to IET= F > datatracker, includes Section 4.5 Direct Measurement TLV. It is noted in > the section: > The Direct Measurement TLV enables collection of the number of in- > profile packets, i.e., packets that form a specific data flow, that > had been transmitted and received by the Session-Sender and Session- > Reflector, respectively. The definition of "in-profile packet" is > outside the scope of this document and is left to the test operators > to determine. > Thus I cannot see any technical need for the introduction of yet another > way of direct loss measurement in STAMP. As for the case of TWAMP Light, = I > believe that there's no sufficient evidence that the proposed direct > loss-measurement measurement method benefits existing implementations of > TWAMP Light. Also, historically, all extensions applicable to TWAMP Light > have been introduced through extending TWAMP proper, i.e., extending > TWAMP-Control and TWAMP-Test. The way of "extending" TWAMP Light presente= d > in the drafts we are discussing is, in my opinion, in violation of RFC 53= 57. > > More notes can be found below. > > Regards, > Greg > > > On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgandhi) > wrote: > >> Thank you Greg for your further reply and the discussions. >> >> *Good to know that you do see a need for the extensions for the >> direct-mode packet loss detection and the authors are actively working o= n >> an alternate methods using BFD (as you mentioned below).* >> > GIM3>> As you've recognized, in draft-mirmin-bfd-extended > we > build an integrated OAM based on the lightweight Fault Management protoco= l > with optional Performance Monitoring, based on RFC 6374. RFC 6374, in tur= n, > provides a rich set of performance measurement methods, including direct > loss measurement. > > Please see replies inline with =E2=80=A6. >> >> >> >> >> >> *From: *Greg Mirsky >> *Date: *Monday, November 30, 2020 at 11:30 AM >> *To: *Rakesh Gandhi (rgandhi) >> *Cc: *Gyan Mishra , IETF IPPM WG , >> James Guichard , ippm-chairs@ietf.org < >> ippm-chairs@ietf.org>, spring-chairs@ietf.org , >> spring@ietf.org , Greg Mirsky >> *Subject: *Re: [spring] [ippm] WG Adoption Call for >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 >> >> Hi Rakesh, >> >> thank you for the continued discussion. I appreciate your responses. I a= m >> still not convinced of the value these documents add. Please find my >> follow-up notes in-line below under the GIM2>> tag. >> >> >> >> Regards, >> >> Greg >> >> >> >> >> >> On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) < >> rgandhi@cisco.com> wrote: >> >> Thank you Gyan and Greg for your review comments and discussions. Please >> see inline replies with =E2=80=A6 >> >> *From: *Gyan Mishra >> *Date: *Wednesday, November 25, 2020 at 12:34 PM >> *To: *Greg Mirsky >> *Cc: *IETF IPPM WG , James Guichard < >> james.n.guichard@futurewei.com>, Rakesh Gandhi (rgandhi) < >> rgandhi@cisco.com>, ippm-chairs@ietf.org , >> spring-chairs@ietf.org , spring@ietf.org < >> spring@ietf.org> >> *Subject: *Re: [spring] [ippm] WG Adoption Call for >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 >> >> Hi Rakesh >> >> I have been following this thread and to help progress the discussion I >> would like to provide some comments in-line Gyan> >> >> Thanks >> >> Gyan >> >> On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky >> wrote: >> >> Hi Rakesh, >> >> thank you for the response to my comments. Please find my follow-up note= s >> in-lined below under the GIM>> tag. >> >> Regards, >> >> Greg >> >> On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) < >> rgandhi@cisco.com> wrote: >> >> Thank you Greg for taking time for thoroughly reviewing the documents an= d >> providing the comments. >> >> Please see replies inline with =E2=80=A6 >> >> *From: *ippm >> *Date: *Friday, November 6, 2020 at 11:18 AM >> *To: *James Guichard >> *Cc: *spring@ietf.org , ippm-chairs@ietf.org < >> ippm-chairs@ietf.org>, spring-chairs@ietf.org , >> IETF IPPM WG >> *Subject: *Re: [ippm] [spring] WG Adoption Call for >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 >> >> Dear Chairs of the SPRING and IPPM WGs, Authors, et al., >> >> I've found myself in the situation when two related drafts are in the WG >> APs in the SPRING and IPPM WG (with the possibility that expertise from = the >> third WG, BFD WG, might be desirable to review the "liveness monitoring"= ). >> Because these drafts are closely related, I've decided to combine my >> questions and comments in a single thread. I hope that would be acceptab= le >> and considered by the SPRING WG as well as IPPM WG. >> >> Usually, the bar for the adoption of a document can be evaluated by >> answers to these three questions: >> >> - Is the document(s) reasonably well-written >> >> I've got surprised that the drafts don't use the terminology from RFC >> 4656 and 5357 and introduce their own terminology for Session-Sender and >> Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are >> used in the documents without proper definitions. Other than that both >> drafts are readable and reasonably well-written. >> >> We are ok to change Sender to Session-Sender and Reflector to >> Session-Reflector if it helps. >> >> >> >> GIM>> I believe that the consistency in terminology between the core RFC >> and what is intended as its extension is not only helpful to a reader bu= t, >> to the best of my understanding, is required for IETF specifications. Bu= t I >> don't think that switching the terminology will fix the fundamental issu= e >> with the proposal. The operation that is required from the remote entity= , >> whether it is referred to as responder or Session-Reflector, is not defi= ned >> in Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinio= n, >> the behavior required, as described in the draft, cannot be characterize= d >> as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completel= y >> new protocol that, if there's a need in the new PM OAM protocol, must be >> properly defined. >> >> Gyan> I am in complete agreement with Greg about terminology and >> consistency. The problem with inconsistency is that that you are not >> following well known normative references required to understand the >> specification leading to confusion and misunderstanding of the >> specification. The goal should be clear and concise in terminology and >> verbiage. >> >> Agree. Will address the terms from RFC 5357 in the next revision. >> >> There are many existing RFCs that use term =E2=80=9CLink=E2=80=9D (= e.g. RFC 5613, >> 5340, 8330, etc.) and term =E2=80=9CCongruent Path=E2=80=9D (e.g. RFC 59= 21, 6669) without >> defining them. I suspect it is because these are well-known terms. Havin= g >> said that, we can add a reference for them if it helps. >> >> GIM>> Thank you for listing these RFCs. I think I need to clarify my >> questions. While a reference to any of RFCs you've mentioned, I don't th= ink >> that will address my concern. In reviewed documents, "Link" is capitaliz= ed >> while referenced RFCs used the lower case form for the term "link". Can >> these be used interchangeably? Do they refer to the same network object? >> >> Now I'll try to illustrate my concern with using the term "congruent >> path" in these drafts (using ASCII-art): >> >> C---------D >> >> / \ >> >> A----B E-----F >> >> \ / >> >> G------------H >> >> Consider an SR tunnel from A to F that traverses the network as >> A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of >> "congruent" as "two figures or objects are congruent if they have the sa= me >> shape and size, or if one has the same shape and size as the mirror imag= e >> of the other", it looks as the path A-B-G-H-E-F is congruent to that SR >> tunnel. But a packet of an active OAM intended to monitor a flow over th= e >> SR tunnel is out-of-band relative to that flow and will not produce any >> meaningful measurement. Of course, for the case of the extensions in dra= fts >> *-twamp-srpm, direct loss measurement can be performed, as information >> collected from node F and packets that collect the counters are not >> required to be in-band with the monitored flow. So, this example, in my >> opinion, illustrates two of my concerns: >> >> =C2=B7 using a congruent path for active performance measurement= , >> e.g., TWAMP or TWAMP Light, may produce information that does not reflec= t >> the condition experienced by the monitored flow. It seems that the >> terminology should reflect the fundamental requirement of ensuring that >> active OAM test packets are in-band with the monitored flow. >> >> =C2=B7 there are no technical requirements to justify using in-b= and >> test packets for direct packet loss measurement. In fact, using the in-b= and >> method for collecting in-profile counters leads to a waste of bandwidth, >> which may have a negative impact on services that require low-latency >> and/or low packet loss. As demonstrated in this example, direct packet l= oss >> can be performed using an out-of-band mechanism, e.g., SNMP queries, >> Netconf notifications based on YANG data model. >> >> >> - Does the document solve a real problem? >> >> No, it appears that these drafts define a new performance measurement >> protocol for the purpose of combining OWAMP and TWAMP functionality and >> adding the ability to collect counters of "in-profile" packets. I couldn= 't >> find sufficient technical arguments for using a PM protocol instead of, = for >> example, extending the existing OAM mechanisms like ICMP. >> >> Gyan> This may sound basic but is a very critical subject going down >> the same lines of clarity in verbiage so their is no misunderstanding. >> =E2=80=9CCongruent=E2=80=9D by definition means shape of an object and = if you super >> imposed two objects on top of each other they fit perfectly and the edge= s >> coincide identically. The problem with congruent is that it is based on >> the shape and that shape could be a mirror image or reflection which may >> not be exact. So when referring to a SR-TE path taken this could lead t= o >> confusion as to path taken if it=E2=80=99s the same path or congruent wh= ich is >> vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here the= re is criticality >> as to the path being referenced in terms of in-band versus out-of-band. = I >> agree that for direct in band packet loss measurement can be done via >> existing OAM mechanisme via ICMP. >> >> Ok, we will find an appropriate term for =E2=80=9Csending packets = on the >> same path as data traffic=E2=80=9D. >> >> Extending ICMP for direct-mode loss measurement is outside the >> scope of this draft. But good to see the agreement for the direct in ban= d >> packet loss measurement to be done (albeit by some other means). >> >> GIM2>> I feel that you misunderstand my position in regard to the use >> case these four documents try to solve. I don't recall that I've stated >> that "direct in-band packet loss measurement" requires any additional >> standardization work. The Direct Measurement TLV has solved that for STA= MP >> and draft-ietf-ippm-stamp-option-tlv is now in the RFC Editor's queue. I >> cannot find any valid technical reason to re-open this and measure the >> direct packet loss in a slightly different way. I must point out that a >> claim that using fixed positions for the direct packet loss optimizes >> performance does not stand for cases (Section 4.2.1 and 4.2.2 of >> draft-gandhi-spring-stamp-srpm) when the return path is specified in the >> Return Path TLV and, as I understand it, in some cases even the second T= LV, >> Node Address TLV, is used. Thus, it is clear that the proposed new metho= d >> of direct packet loss measurement does not offer any significant benefit= s >> comparing to the STAMP's Direct Measurement TLV and appears nothing but >> superfluous. >> >> >> >> The direct-mode packet loss use-case is typically for the forward >> direction packet loss. And this does not use the return path TLV. We can >> clarify that in the draft. >> > GIM3>> Clarification would be very helpful as your latest note might be > interpreted that the proposed mechanisms are not applicable in the case o= f > a bi-directional SR tunnel. > >> There is a requirement to measure performance delay as well as >> synthetic and direct-mode packet loss in segment-routing networks. OWAMP >> and TWAMP protocols are widely deployed for performance delay and synthe= tic >> packet loss measurement today. I am not sure extending ICMP for LM is a >> good option here. >> >> GIM>> I agree with the requirements you've listed (though the SPRING WG >> OAM requirements document >> ha= s >> been abandoned and expired 3+ years ago). I believe that there's no >> sufficient technical reason to use OWAMP/TWAMP for exclusive direct pack= et >> loss measurement. >> >> Gyan> Agreed >> >> There is definitely a need to do direct-mode loss measurement in >> IP/SR networks, as RFC 6374 mechanisms are for MPLS networks. Note that >> there was an attempt to extend BFD for direct-mode loss measurement for >> this purpose using RFC 6374 loss measurement message (see >> draft-mirmin-bfd-extended-03). >> >> GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended >> in >> the past tense. The work and discussion of the proposal continues and th= e >> new version will be published soon. >> >> >> >> * Ok, so you do see a need for the extensions for the direct-mode >> packet loss detection and the authors are actively working on an alterna= te >> methods using BFD. * >> >> >> - Is the proposed solution technically viable? >> >> There are too many unaddressed aspects, particularly the risk introduced >> by the protocol on network security, to comprehensively evaluate the >> proposed solution. >> >> About your comment on zero checksum, this is described in Security >> section in RFC 6936. We will add reference to this RFC in our Security >> Section as well. This is only specific to the UDP port locally provision= ed >> in the domain by the operator for TWAMP. Other than this, I did not find >> any other security related issue in your review below. >> >> GIM>> I don't think that a mere reference sufficiently explains why the >> use of zero UDP checksum in IPv6 header is not decremental, does not cre= ate >> a security risk for the protocol. >> >> Gyan> Agreed 0 UDP MIMA security threats and that you need to >> thorough vetting of RFC 6936. >> >> Yes, will add in the next revision. Hope we can work together on >> needed text. >> >> To summarize my review of these two drafts: >> >> - these propose a new protocol, not an update or enhancement of the >> TWAMP-like protocol; >> >> The probe and response messages defined in [RFC 5357] are used for >> delay measurement and synthetic packet loss. The direct-mode packet loss >> messages are defined in draft-gandhi-ippm-twamp-srpm >> that >> match these delay measurement messages. As stated, >> draft-gandhi-ippm-twamp-srpm >> defines >> =E2=80=9Cextensions=E2=80=9D for TWAMP Light. >> >> GIM>> I cannot find where RFC 5357 defines "the probe and response >> messages". Could you give a more specific reference or provide the text >> that, in your opinion, defines such messages? But I'm more concerned wit= h >> the direction of "extending" non-protocol referred to as "TWAMP Light". = As >> a contributor to BBF's TR-390, I'm have learned how different are existi= ng >> implementations of TWAMP Light. And that is also noted in EANTC >> Multi-Vendor Interoperability 2019 white paper >> . >> The status of TWAMP Light is explained in RFC 8545 and I cannot see that= it >> can be used as a foundation of any standard. >> >> Gyan> I don=E2=80=99t see the probe a d response messages in TWAMP RFC= 5357 >> >> Agree to use term test-packet from RFC 5357. >> >> =C2=B7 several parts of the proposed protocol, e.g., Zero UDP >> checksum in IPv6, require detailed security analysis, which is currently >> absent; >> >> Gyan> Agreed >> >> Please see previous reply. >> >> This is specified in RFC 6936 Security Section. We will add >> reference to this RFC in our Security Section as well. This is only >> specific to the UDP port locally provisioned in the domain by the operat= or >> for TWAMP. >> >> GIM>> I've noted above that a simple reference does not sufficiently >> explains why the use of zero UDP checksum in IPv6 header is not >> decremental, does not create a security risk for the protocol. I believe >> that the proposal to use zero UDP header checksum requires extensive >> analysis, using the analysis provided in RFC 6936. >> >> Gyan> Completely Agree >> >> Please see previous reply. >> >> >> - I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on >> the Informational track even though it is essential to the new protoc= ol as >> it defines its key elements >> >> This was to address your previous comment quoted as: >> >> =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode= , >> >> mentioned in the informational Appendix I in RFC 5357, not the TWAMP >> >> protocol itself. Since TWAMP Light is not a standard but its idea is >> >> described in the informational text only, I think that the >> Informational >> >> track is more appropriate for this specification.=E2=80=9D >> >> https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ >> >> Having said that, we are ok to change to PS. >> >> GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. >> If anyone is interested in standardizing an "extension", I'd expect that >> they first define the base specification to which the extension applies.= I >> might have missed the definition of TWAMP Light protocol in the draft. C= ould >> you point to the definition, for example, of the Authenticated mode in >> TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? >> >> Gyan> Agreed >> >> The Appendix I of RFC 5357 does have information on the >> Authentication mode. As specified there, this is based on user configure= d >> parameters. >> >> =C2=B7 I believe that draft-gandhi-spring-twamp-srpm should be >> anchored at IPPM WG as it does introduce the new PM protocol. >> >> The TWAMP Light extension draft-gandhi-ippm-twamp-srpm >> is >> already in IPPM WG. The SPRING draft only defines SR PM procedures. >> >> Below, please find my detailed comments, questions on these drafts: >> >> - draft-gandhi-spring-twamp-srpm >> >> I have several questions about the relationships between this draft and >> Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light has >> been mentioned. The nature of the TWAMP Light and what is required to ma= ke >> it a standard is well-explained in Section 4 of RFC 8545 >> (apologies for the long >> quote): >> >> "TWAMP Light" is an idea described in Appendix I ("TWAMP Light >> (Informative)") of [RFC5357]; TWAMP Light includes an unspecified >> control protocol combined with the TWAMP-Test protocol. In >> [RFC5357], the TWAMP Light idea was relegated to Appendix I because >> TWAMP Light failed to meet the requirements for IETF protocols (there >> are no specifications for negotiating this form of operation and no >> specifications for mandatory-to-implement security features), as >> described in Appendix A of this memo. See also [LarsAD] and >> [TimDISCUSS]. >> >> Since the idea of TWAMP Light clearly includes the TWAMP-Test >> component of TWAMP, it is considered reasonable for future systems to >> use the TWAMP-Test well-known UDP port (whose reallocated assignment >> is specified in this document). Clearly, the TWAMP Light idea >> envisions many components and communication capabilities beyond >> TWAMP-Test (implementing the security requirements, for example); >> otherwise, Appendix I of [RFC5357] would be one sentence long >> (equating TWAMP Light with TWAMP-Test only). >> >> Since we don't have an IETF document that addressed these open >> questions, I don't think we can have a draft that proposes extensions to= a >> non-standard mechanism (Appendix is for Informational material, as I >> understand it) on the Standard track. >> >> Gyan> Agreed >> >> The procedure for using the RFC 5357 defined messages in TWAMP >> Light configuration mode is defined in the corresponding spring drafts. = It >> also describes the provisioning model. >> >> GIM2>> If a return path can be provisioned for TWAMP Light, why the same >> method of controlling a test session cannot be used for STAMP? >> >> >> >> It is not expected that all STAMP TLV extensions need to be >> supported for TWAMP Light using provisioning. >> > This was to address your previous comment quoted as >> >> =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode= , >> >> mentioned in the informational Appendix I in RFC 5357, not the TWAMP >> >> protocol itself. Since TWAMP Light is not a standard but its idea is >> >> described in the informational text only, I think that the >> Informational >> >> track is more appropriate for this specification.=E2=80=9D >> >> https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ >> >> Having said that, we are ok to change to PS as you mentioned above. >> >> BTW, despite only difference of fixed vs. variable length payload i= n >> STAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and= it >> uses the same approach of provisioning as defined in this draft). Hence= , >> security considerations for STAMP and TWAMP Light are not different. Not= e >> that both STAMP and TWAMP Light have authenticated messages defined for >> Security purpose. >> >> GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the >> light, simpler, version of TWAMP-Test component of TWAMP protocol. I can= not >> find in draft-gandhi-spring-twamp-srpm definition of the Authenticated m= ode >> of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the >> discussion of "extension" to TWAMP Light. >> >> The Authentication information is user-configured as shown in >> Section 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described= in >> Appendix I of RFC 5357. >> >> Now a number of more specific questions. >> >> draft-gandhi-spring-twamp-srpm: >> >> - In the Introduction it is stated that: >> >> The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides >> simplified mechanisms for active performance measurement in Customer >> IP networks by provisioning UDP paths and eliminates the need for >> control-channel signaling. >> >> I can not find where, either Appendix I or TR-390, "eliminated the need >> for control-channel signaling". Also, could you point where the referenc= ed >> documents describe "provisioning UDP paths"? >> >> The Appendix I of RFC 5357 has following text. We can reword and ma= tch the exact text if you prefer. >> >> >> >> =E2=80=9CThis example eliminates the need for the TWAMP-Control protocol= , and >> >> assumes that the Session-Reflector is configured=E2=80=9D >> >> GIM>> I think that the text you're proposing is even more confusing. It >> is not clear which example the sentence is referring to. Also, what is t= he >> basis for such an assumption? >> >> This is the exact text from RFC 5357 Appendix I. Please go through >> the entire Section in that RFC 5357 to avoid =E2=80=9Cout of context=E2= =80=9D discussion. >> >> >> - It appears that the last paragraph in the Introduction describes >> the relationship with Appendix I of RFC 5357: >> >> The procedure uses the mechanisms defined in [RFC5357] >> (TWAMP Light) and its extensions for Performance Measurement. >> >> I think that the reference must be to Appendix I, not RFC 5357. Also, >> could you please specify which extensions of TWAMP Light have been used = in >> this draft? >> >> We can add the Appendix I as reference in the next revision. >> Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add this >> reference. >> >> GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a >> normative reference while it is, by its nature, an Informational documen= t. >> >> If approved, it is fine to have informational draft/RFC in a >> normative reference. But RFC 5357 is PS. >> >> >> - In Section 2.3 describing the reference model is noted: >> >> The probe response message is typically sent to the sender node R1. >> >> In which scenarios the reflector acts differently? How such behavior is >> related to the behavior of a TWAMP Session-Reflector, as defined in RFC >> 5357? >> >> Do you prefer we remove =E2=80=9Ctypically=E2=80=9D from the senten= ce? >> >> GIM>> If that fits into the operational model of the new protocol you're >> defining. >> >> >> - Also in Section 2.3 a Link is mentioned as an element directly >> connecting nodes in the presented reference model. Could you clarify = what >> is a Link? Is it always a physical connection between two systems or = a >> virtual? >> >> Both, please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well know= n term used in >> many existing RFCs (please see RFC 5613, 5340, 8330). >> >> GIM>> Thank you for the references. I couldn't find a definition of an >> object "Link" (capitalized) but only "link" (lower case). Hence, since t= he >> draft consistently uses the capitalized form, I consider it to be someth= ing >> else, something different from a link. >> >> Ok, we can change Link to link in the next revision to avoid >> confusion. >> >> >> - In Section 3 behavior of the reflector described as >> >> ... no PM state for delay or loss measurement need to be created on t= he >> reflector node R5. >> >> That is in contradiction to the behavior of a TWAMP Session-Reflector as >> defined in RFC 5357. Could you provide a reference to an IETF standard >> where this behavior is defined? Also, how, without creating a state at t= he >> Session-Reflector, to achieve one-way delay and synthetic loss measureme= nt >> on a bidirectional SR tunnel? >> >> Gyan> Valid point >> >> Bidirectional SR tunnel may have an SR state but the statement >> above is that no PM (i.e. TWAMP Light) protocol session state is created >> for it. We can clarify in the next revision. >> >> GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one >> option. I am well-familiar with the implementation that uses the statefu= l >> mode. >> >> >> >> What information stateful PM need to maintain in the state on the >> reflector? Doesn=E2=80=99t that cause scale issues. We can add in the dr= aft you if >> there is anything specifically needed in the spec. >> > GIM3>> RFCs 5357 and 8762 are clear about what information must be > maintained by a Session-Reflector. The Session-Reflector must have > knowledge of the test session state and count reflected test packets. The > value of such a counter must be copied in the Sequence Number field of th= e > reflected packet. Thus the method enables the measurement of the one-way > packet loss metric. > >> Quoting the text from Appendix I in RFC 5357. We can quote the >> text as is. >> >> =E2=80=9CIn the case of TWAMP Light, the Session-Reflector does not nece= ssarily have knowledge of the session state. =E2=80=9C >> >> GIM>> By the informational nature of Appendix I, the text is not >> normative. I am familiar with the implementation of TWAMP Light which do= es >> maintain the session state and thus supports one-way packet loss >> measurement. If you require that the remote node does not maintain the >> state, the draft must define that as part of the specifying the behavior= of >> the protocol. >> >> Ok, we can discuss what information is to be maintained in that >> state on the reflector for synthetic packet loss. We can add appropriate >> text if you can help please. >> >> GIM2>> I don't see any reason to do that as that already defined in RFC >> 8762 and draft-ietf-ippm-stamp-yang >> >> >> >> >> Ok. >> >> =C2=B7 Further, in Section 3 the selection of UDP port explained= as >> the following: >> >> As specified in [RFC8545], the reflector >> supports the destination UDP port 862 for delay measurement probe >> messages by default. This UDP port however, is not used for loss >> measurement probe messages. >> >> To the best of my understanding, as one of the contributors and Editors >> of RFC 8545, it re-allocated UDP port 862 for use by a TWAMP >> Session-Reflector without excluding any type of measurement. Besides, in >> TWAMP delay and packet loss are measured in the same test session, using >> the same flow of TWAMP-Test packets. >> >> Gyan> Agreed >> >> Yes, we can use port 862 for both delay and synthetic packet loss = =E2=80=93 >> they are using the same test packet. There is no change proposed in the >> draft. >> >> GIM2>> Packet delay and synthetic packet loss measurements are already >> supported in RFC 8762. Are you proposing a new protocol to duplicate the >> STAMP functionalities? >> >> >> >> As mentioned, the extensions defined are for the direct-mode packe= t >> loss measurement for TWAMP Light and STAMP. >> >> The packet loss in existing RFC 5357 refers to synthetic loss as >> there is no support for direct-mode loss in RFC 5357. We can change the >> text to clarify as =E2=80=9CThis UDP port however, is not used for direc= t-mode loss >> measurement probe messages.=E2=80=9D >> >> GIM>> I've found that there's some misconception in the draft. RFC 8545 >> re-assigned UDP port 862 not for "delay measurement probe messages" but = for >> TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay= , >> packet loss, reordering (RFC 4737 defines packet reordering metric), and >> packet duplication measurement. >> >> >> - Then the draft states that >> >> The sender uses the UDP port number following the guidelines specified i= n >> Section 6 in [RFC6335]. >> >> Could you point to the guidelines that a user can use when selecting a >> UDP port number of a test session? >> >> Gyan> Good point >> >> Please see section 6 in [RFC6335]. We can cite the range which will >> be the same as used in [RFC8762]. This was also discussed earlier. >> >> https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ >> >> GIM>> I've looked through Section 6 but I don't find anything >> specifically applicable to this draft we're discussing. If the protocol = to >> use UDP port numbers from the Dynamic ports range, a.k.a., Private or >> Ephemeral, then it seems that stating that explicitly would be the best >> way. >> >> This would be, User Ports and Dynamic Ports ranges, which are defi= ned in [RFC6335 ]. Yes, we can add thi= s text. >> >> >> - At the closing of the paragraph, we read that >> >> The number of UDP ports with PM functionality needs to be minimized du= e >> to limited hardware resources. >> >> Does a UDP port number pose PM functionality? How it is assigned to the >> port number? >> >> UDP ports are user configured for delay and direct-mode loss PM as >> described in Section 3.1. >> >> GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss >> measurement uses port number different from the one used by a TWAMP-Test >> packet, in my opinion, is another indication that this is the definition= of >> a different from TWAMP Light PM OAM protocol. >> >> If we add a field in the packet then UDP port 862 may be used alon= g >> with the new field. But it will require extra processing in hardware. It= is >> better to use a different UDP port for processing efficiency in hardware= . >> >> >> - Following the above-quoted text, in Section 3 is noted: >> >> For Performance Measurement, probe query and response messages are >> sent as following: >> >> Could you clarify if the listed further procedures deviate from >> OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for >> Session-Sender and Session-Reflector respectively? >> >> Probe messages follow the same procedure as defined in RFC 4656 and >> RFC 5357. >> >> GIM>> All messages, i.e., TWAMP-Test packets as well as the defined >> in draft-gandhi-ippm-twamp-srpm? >> >> Yes, unless otherwise specified in the >> draft-gandhi-ippm-twamp-srpm. >> >> >> - for both delay and loss measurements draft requires test packet be >> transmitted on a congruent path: >> >> the probe messages are sent on the >> congruent path of the data traffic by the sender node >> >> It is not clear what "the congruent path" means. The definition >> of congruency in geometry tells us that an object B is congruent to obje= ct >> A if it has the same shape and size, but is allowed to flip, slide or tu= rn. >> How a path can be congruent to another path? >> >> Gyan> Agreed. The use of congruent in the context of pathing is >> confusing as the path being addressed may not be reflected accurately by >> the term congruent. >> >> As replied above. >> >> There are many existing RFCs that use term Congruent Path (e.g. RFC >> 5921, 6669) without defining them. I suspect it is because it is well-kn= own >> term. Having said that, we can add a reference for it if it helps reader= . >> >> GIM>> I cannot assume what was the context of these RFCs. I've sketched = a >> network diagram above to illustrate that a "congruent path" may well lea= d >> to out-of-band path. Is that the intention of the authors of the draft t= o >> use this protocol out-of-band? >> >> As replied above. >> >> >> - The last paragraph in Section 3 refers to work on iOAM: >> >> The In-Situ Operations, Administration, and Maintenance (IOAM) >> mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for >> SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM >> information such as timestamp in-band as part of the data packets, >> and are outside the scope of this document. >> >> Is iOAM in the scope of this specification? What are the relationships >> between iOAM and draft-gandhi-spring-twamp-srpm? >> >> As mentioned in the draft, IOAM is outside the scope. >> >> GIM>> Yes, but it appears that references to the two IOAM-related drafts >> have some purpose. What is it? How are these drafts related >> to draft-gandhi-spring-twamp-srpm? >> >> We can remove them if it is confusing. It is informational text >> (was added to address a review comment). >> >> >> - Section 3.1 presents an example of the provisioning model but puts >> the definition of the provisioning model outside the scope. Is there = an >> accompanying specification that defines the provisioning model that c= an be >> used in multi-vendor deployment? Could that be YANG data model? What = is the >> relationship with draft-ietf-ippm-twamp-yang >> ? Would >> the TWAMP YANG data model be augmented? >> >> Yes, this can be Yang model. We can review >> draft-ietf-ippm-twamp-yang >> and add any >> missing items in a separate draft. We can also add a reference in this >> draft. >> >> GIM>> I think that theremust be some discussion on how the new protocol >> is configured. If TWAMP YANG data model can be augmented, I'd expect tha= t >> being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anyth= ing >> about the configuration of the protocol. >> >> The Yang model extensions are not in the scope of this draft >> >> >> - Section 4.1 states that a new message is introduced to perform the >> Loss Measurement in this protocol Why the capability of TWAMP to meas= ure >> the loss in one-way and two-way is not sufficient? >> >> Existing TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80= =9D loss >> measurement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to cla= rify. >> >> GIM>> True, direct loss measurement, in fact, is not active measurement >> and thus is outside the scope of Two-Way Active Measurement Protocol >> (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, >> passive measurement method and fetching counters can be done using numer= ous >> methods, e.g., SNMP, Netconf >> >> RFC 7799 does not say using Test-packets to collect counters for >> direct-mod loss measurement is passive. >> >> GIM2>> Per RFC 7799, injecting in-band test packets is the characteristi= c >> of an active measurement method. Using out-of-band transport, e.g., SNMP >> queries, would be an example of a passive measurement method. >> >> >> >> Ok, so you answered your own question that the direct-mode packet >> loss extension defined is =E2=80=9Cactive measurement=E2=80=9D method. >> >> >> - Section 4.1.1 requires that >> >> The Destination UDP port cannot be used as Source port, since >> the message does not have any indication to distinguish between the >> query and response message. >> >> Does that imply that the Destination UDP port used for the Delay >> measurement is unique throughout the particular domain? >> >> Gyan> Good question >> >> Yes, it is unique in the domain. >> >> This is user-defined and is up to the user what UDP port to >> provision in a domain. >> >> GIM>> So, can user configure a port number from the User Ports range? Or= , >> can the same port number be used on the same system for a number of test >> sessions? I find the use of UDP port numbers being underspecified. >> >> >> - Section 4.1.2 of RFC 5357 does not define "the delay measurement >> message" but refers to the definition of the Session-Sender's test pa= cket >> in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test >> packet format to perform both delay and packet loss measurement. >> >> Ok, we can update the text in the next revision to indicate exact >> name from the RFC 4656. We can also add text to include synthetic packet >> loss. >> >> GIM>> I think that making it explicit would help. Also, that will >> highlight what is being introduced by *twamp-srpm drafts is, in fact, a = new >> protocol to perform synthetic packet loss measurement. >> >> No, it does not change anything for synthetic packet loss. >> >> >> - Can you explain how "the DM probe query message contains the >> payload format defined in Section 4.2.1 of [RFC5357]" when the refere= nced >> section of RFC 5357 defines the format of a Session-Reflector's test = packet? >> >> We can update the text in the next revision to indicate query forma= t >> name from RFC 5357. >> >> GIM>> I cannot find any reference to a query format in RFCs 4656/5357. >> Could you please quote from any of these documents? >> >> It is test-packet, we will use RFC 5357 term. >> >> >> - Can clarify the applicability of RFC 6038 and the symmetrical >> packet size? Is it required? Can it be non-symmetrical? >> >> Yes. Please see section 4.1.1 and quoted below: >> >> =E2=80=9CFor symmetrical size query and response messages as defined in = [RFC6038],=E2=80=9D >> >> GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the >> symmetrical test packets. Since *-twamp-srpm proposals do not use >> TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about >> that either (in part because RFC 6038 came later), I don't see that ther= e's >> any certainty in what is the sze of a test packet used in the direct-los= s >> measurement. >> >> The test-packets as defined in these existing RFCs are used for >> delay and synthetic packet loss. The direct-mode test-packets are define= d >> in this draft. >> >> GIM2>> This draft defines only a new packet format for the direct packet >> loss measurement. For STAMP such a mechanism is clearly superfluous give= n >> the Direct Measurement TLV is already defined. >> >> >> >> As replied earlier. >> >> >> - Can you clarify the use of the timestamp format, NTP or PTPv2? It >> is not clear which is the default, mandatory or optional. >> >> This is same as TWAMP. There is no change. >> >> GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for >> *-twamp-srpm? >> >> No change in existing in what is there in RFC 5357 and RFC 8186. >> >> >> - Also, is "hardware support in Segment Routing networks" of the >> PTPv2 format required, guaranteed, or something else? >> >> Hardware timestamps are recommended for SR use-cases. We can change >> the sentence. >> >> GIM>> Perhaps you can propose some text, that would be helpful. >> >> Ack. >> >> >> - Section 4.1.1.1 stated that >> >> A separate user-configured >> destination UDP port is used for the delay measurement in >> authentication mode due to the different probe message format. >> >> Can that be interpreted that there could be concurrent authenticated and >> unauthenticated test sessions using this protocol? Would different >> authentication methods require using unique destination UDP port numbers= ? >> >> Yes, and Yes, and these are based on provisioning. >> >> GIM>> But that requirement is far outside the TWAMP, as defined in RFC >> 5357. >> >> Some Session-Sender can use authenticated and some not. It is >> part of RFC 5357. >> >> >> - Section 4.1.2 by introducing the dedicated Loss measurement packet >> format, effectively modifies the behavior defined in RFC 5357 for >> Session-Sender and Session-Reflector. But the document does not state= that. >> Can you clarify whether this specification changes the behavior of a >> Session-Sender and Session-Reflector as defined in RFC 4656 and RFC 5= 357 >> respectively for the support of packet loss measurement? >> >> The direct-mode loss defines new procedure for sender/reflector to >> collect traffic counters, as opposed to timestamp. The rest is the same = as >> RFC 4656 and 5357. >> >> GIM>> I cannot agree with your statement " The rest is the same as RFC >> 4656 and 5357" because the sender's direct-loss format does not have Err= or >> Estimate field, Thus, a reflected packet does not have Sender's Error >> Estimate, nor Error Estimate of the reflector. And that, in my opinion, = is >> another clear indication that *twamp-srpm drafts define a new protocol, >> separate from OWAMP/TWAMP. >> >> That field is specific to timestamps and would not apply to >> counters for direct-mode loss measurement. >> >> >> - And a similar question about the use of the separate UDP port >> number for the authenticated of the packet loss measurement. >> - A couple of question to the following text in Section 4.1.3: >> >> The local and remote IP >> addresses of the link are used as Source and Destination Addresses. >> They can also be IPv6 link local address as probe messages are pre- >> routed. >> >> - What are the addresses of a link? >> >> I am assuming this well-known (e.g. RFC 2328). >> >> GIM>> I am not familiar with the term "pre-routed". What does it mean? >> >> Ensure that packets are routed over the link. >> >> >> - In which scenarios an IPv6 LLA can be used? >> >> I am assuming this is well-known (e.g. RFC 5613). >> >> GIM>> So, LLA may be used as the source and destination addresses when >> testing an SR tunnel? >> >> As mentioned this is for links. >> >> >> - Also, could the use of a routable destination IP address be used as >> a DDOS attack vector? Consider the scenario when an attacker gener= ates >> SR-encapsulated packets with the destination IP address other than= any of >> the SR-terminating nodes. Such a packet will be routed, correct? T= hat does >> appear as a security threat, would you agree? >> >> Absolutely do not agree. It is no different than IP routed TWAMP >> packet as defined in [RFC5357]. >> >> GIM>> You don't agree that the processing described cannot happen becaus= e >> of laws of physics or it wouldn't happen because no one will think of th= at? >> If the latter, I think that that is security threat. >> >> There is no new threat like you have mentioned. >> >> GIM2>> Hmmm, but how the integrity of TLVs proposed >> in draft-gandhi-ippm-stamp-srpm can be protected? These are not protecte= d >> by HMAC as presented in figures 3 and >> 5. >> >> >> >> >> The extensions do not change the processing of these existing TLVs >> defined for HMAC. We can add text to indicate this. >> >> >> - Section 4.1.4.2 references Figure 5 that, as I understand it, >> displays the format of a probe query message. In figure two reference= s to >> RFC 5357 are provided - a section that references RFC 4656 OWAMP defi= nition >> of the Session-Sender test packet, and a section that defines the >> Session-Reflector's reflected packet. Which of the two is used for th= e >> delay measurement in the proposed protocol? >> >> The probe query packet in the Session-Sender text packet. We can >> update the name. >> >> - Section 4.2.1 states that >> >> In one-way measurement mode, the probe response message as defined in >> Figure 6 is sent back out-of-band to the sender node ... >> >> Could you clarify how the responder controls that the response packet is >> sent not in-band but out-of-band? >> >> Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This >> is existing behaviour for out-of-band. >> >> GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines >> another new protocol OWAMP Light. And it is not clear what you reference= as >> "this is existing behavior". Is it to reference behavior of TWAMP test >> packet? But the behavior of the TWAMP-Test protocol by itself is neither >> in-band, nor out-of-band. It is the encapsulation of the TWAMP test pack= et >> that makes it either in-band or out-of-band. >> >> Right. >> >> >> - How's the method described in Section 4.2.3 is different from the >> method described in RFC 8403 ? >> What is distinctly unique about the loopback mode proposed in the sec= tion? >> >> There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 840= 3. >> >> GIM>> So, you believe that proposing to use the method described in RFC >> 8403 for the TWAMP packet is innovation? And what are the benefits of us= ing >> the TWAMP test packet format in the Loopback mode? >> >> Please see the draft. >> >> >> - What is the rationale for setting TTL/Hop Limit fields always to >> 255 for IPv4, MPLS, and IPv6 (per Section 4.3.1)? >> >> This is as defined in Section 4.2 of RFC 5357 (Bullet 4). >> >> GIM>> I believe you've misunderstood the text in RFC 5357. This bullet >> specifies the behavior of a Session-Reflector. It is to try to read TTL >> value of the received TWAMP test packet and copy the value in Sender TTL >> field of the reflected packet. If the Session-Reflector cannot access th= e >> TTL field, it MUST write 255 in the Sender TTL field. So, I think that m= y >> questions still remains. >> >> Please see Section 4.2.1 of RFC 5357. >> >> >> - Section 4.3.3 states that a zero-value UDP checksum may be used in >> some scenarios. RFC 8085 allows that but in very specific cases that = are >> documented in detail in Section 3.4.1. Do you believe that the case o= f this >> protocol checks all the requirements for allowing the use of Zero UDP >> checksum as specified in RFC 8085? Also, I believe that allowing the = use of >> Zero UDP checksum in some scenarios, this protocol introduces a secur= ity >> threat that must be thoroughly analyzed in the Security Consideration= s >> section. >> >> This is described in RFC 6936. It will be very specific to the UDP >> port provisioned for TWAMP. We will add reference to RFC 6936 in Securit= y >> Section. >> >> GIM>> I don't think that the reference is sufficient for the >> Securit Consideration. I'd expect some extended discussion on why using >> zero UDP header checksum is not a security threat for *twamp-srpm proto= col. >> >> Please see reply above. >> >> >> - Section 8 refers to "liveness monitoring of Links and SR Paths". >> This appears as the replication of functionality provided by BFD/S-BF= D >> protocols. Is such comparison accurate? If it is, shouldn't the propo= sal be >> also reviewed by the BFD WG? >> >> TWAMP probe messages are used today for synthetic packet loss whic= h >> can also be used to detect connection loss (performance metric). The >> section simply highlights this obvious metric. >> >> GIM>> Can you point to a document that has defined "TWAMP probe message= s >> are used today for synthetic packet loss"? Also, which document defines >> loss of connectivity as a performance metric? Does *twamp-srpm proposes = to >> use the new protocol to detect the loss of path continuity? >> >> For example Y.1731 has such notion of connection loss. TWAMP is >> used widely for synthetic packet loss and is well-known. There is no cha= nge >> in protocol. This is reported metric. >> >> GIM2>> What are packet transmission frequencies authors envisioned for >> that mode? A single-digit millisecond? >> >> >> >> It depends on the implementation. >> >> >> - I found the Security Section of the proposed protocol inadequately >> terse and missing very important threats that this protocol introduce= s in >> the network. >> >> Other than referring RFC 6936 for zero checksum what else is >> missing? Otherwise it is no different than RFC 8762 (STAMP). >> >> GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The >> use of source IP addresses, as mentioned above, appears to be another >> security risk introduced by *-twamp-srpm drafts. >> >> There is no mention of Source IP address above. >> >> >> - draft-gandhi-ippm-twamp-srpm >> >> As I understand it, the motivation for the Loss Measurement mode defined >> in this specification is to collect "in-profile" counters. Is that corre= ct? >> Do you see as essential for this mode that the query messages are in-ban= d >> with the flow being profiled? In your opinion, how using an out-of-band >> method of collecting these counters, e.g., by using ICMP multi-part mess= age >> extension per RFC 4884, could affect the accuracy comparing with the met= hod >> in this protocol? How the impact changes if extended ICMP messages are >> in-band with the profiled flow? >> >> Yes, they need to be in-band with the flow, to collect the counte= r >> from the right forwarding paths for the flow. Discussion of using ICMP f= or >> direct-mode loss measurement is outside the scope of this draft. >> >> GIM2>> I think that the assumption "they need to be in-band with the >> flow, to collect the counter from the right forwarding paths for the flo= w" >> is technically inaccurate. Otherwise, how SNMP queries could work for >> decades of networking history? >> >> >> >> -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000002dce6a05b5b185f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Rakesh=C2=A0

    Had a general question.

    I read through the draft again and a question came to mind as thi= s draft is Standards Track, what new is being introduced other then a proce= dure of how to use TWAMP in SR networks SR-MPLS which reuses the MPLS data = plane and SRv6 which used the IPv6 data plane.=C2=A0 I don=E2=80=99t believ= e there exists =C2=A0a Standards track draft procedure for how to use STAMP= over IP network or MPLS network as an example. =C2=A0

    Section 4.1.4 describes SR-MPLS use case and= SRv6 use case.=C2=A0 As there appears to be nothing new introduced such as= a new IANA TLV or code point or even a special SID code point =C2=A0for TW= AMP, all basic vanilla SR, that without this draft you could run STAMP, TWA= MP, OWAMP over SR which has existed for a while now. =C2=A0

    What is the new invention here?
    =

    Sorry but I may have missed s= omething.

    My thoughts ar= e at most this be a BCP or I am thinking informational draft would be appro= priate.

    Thoughts?
    <= div dir=3D"auto">
    Gyan

    On Thu, Dec 3, 2020 = at 12:51 PM Greg Mirsky <gregim= irsky@gmail.com> wrote:
    <= div dir=3D"ltr">Hi Rakesh,
    thank you for the continued discussion. You = can find my follow-up notes in-line below under GIM3>> tag. I felt th= at one comment is at the root of our different views on what is considered = to be a problem that drafts solve. You've said:
    =
    <RG3> As mentioned, the extensions defined are for the direct-mo= de packet loss measurement for TWAMP Light and STAMP.
    But draft-ietf-ippm-stamp-option-tlv, currentl= y in=C2=A0 Submitted to IESG for Publication WG state according to IETF dat= atracker, includes Section 4.5 Direct Measurement TLV. It is noted in the s= ection:
    =C2=A0 =C2=A0The Direct Measurement TLV enables collection of t= he number of in-
    =C2=A0 =C2=A0profile packets, i.e., packets that form a= specific data flow, that
    =C2=A0 =C2=A0had been transmitted and received= by the Session-Sender and Session-
    =C2=A0 =C2=A0Reflector, respectively= .=C2=A0 The definition of "in-profile packet" is
    =C2=A0 =C2=A0= outside the scope of this document and is left to the test operators
    =C2= =A0 =C2=A0to determine.
    Thus I cannot see any technical need for = the introduction=C2=A0of yet another way of direct loss measurement in STAM= P. As for the case of TWAMP Light, I believe that there's no sufficient= evidence that the proposed direct loss-measurement measurement method bene= fits existing implementations of TWAMP Light. Also, historically, all exten= sions applicable to TWAMP Light have been introduced through extending TWAM= P proper, i.e., extending TWAMP-Control and TWAMP-Test. The way of "ex= tending" TWAMP Light presented in the drafts we are discussing is, in = my opinion, in violation of RFC 5357.

    More notes c= an be found below.

    Regards,
    Greg


    On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi= (rgandhi) <rgand= hi@cisco.com> wrote:

    Thank you Greg= for your further reply and the discussions.

    Good to kno= w that you do see a need for the extensions for the direct-mode packet loss= detection and the authors are actively working on an alternate methods usi= ng BFD (as you mentioned below).

    GIM3>> As you've recognized, in draft-mirmi= n-bfd-extended=C2=A0we build an integrated OAM based on the lightweight= Fault Management protocol with optional Performance Monitoring, based on R= FC 6374. RFC 6374, in turn, provides a rich set of performance measurement = methods, including direct loss measurement.

    =

    Please see rep= lies inline with <RG3>=E2=80=A6.

    =C2=A0<= u>

    =C2=A0<= u>

    From: Greg Mirsky <gregimirsky@gmail.com= >
    Date: Monday, November 30, 2020 at 11:30 AM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Gyan Mishra <hayabusagsm@gmail.com>, IETF IPPM WG <ippm@ietf.org>, James Guichard &= lt;jame= s.n.guichard@futurewei.com>, ippm-chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs@ietf.org &l= t;spring-chairs= @ietf.org>, spr= ing@ietf.org <s= pring@ietf.org>, Greg Mirsky <g= regory.mirsky@ztetx.com>
    Subject: Re: [spring] [ippm] WG Adoption Call for h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11<= /u>

    Hi Rakesh,

    thank you for the continued discussion. I appreciate= your responses. I am still not convinced of the value these documents add.= Please find my follow-up notes in-line=C2=A0below under the GIM2>> t= ag.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    =C2=A0

    On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

    Thank you Gyan = and Greg for your review comments and discussions. Please see inline replie= s with <RG2>=E2=80=A6

    From: Gyan Mishra <hayabusagsm@gmail.com= >
    Date: Wednesday, November 25, 2020 at 12:34 PM
    To: Greg Mirsky <gregimirsky@gmail.com>
    Cc: IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com&g= t;, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;
    Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11    =

    =C2=A0Hi Rakesh=C2=A0

    I have been following this thread and to help progre= ss the discussion I would like to provide some comments in-line Gyan>=C2= =A0

    Thanks

    Gyan

    On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

    Hi Rakesh,

    thank you for the response to my comments.=C2=A0Plea= se find my follow-up notes in-lined below under the GIM>> tag.=C2=A0<= u>

    Regards,

    Greg

    On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

    Thank you Greg for taking time for tho= roughly reviewing the documents and providing the comments.

    Please see replies inline with <RG&= gt;=E2=80=A6

    From: ippm <ippm-bounces@ietf.org>= ;
    Date: Friday, November 6, 2020 at 11:18 AM
    To: James Guichard <james.n.guichard@futurewei.com>
    Cc: spring@ietf= .org <spring@ie= tf.org>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
    Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11    =

    Dear Chairs of the SPRING and IPPM WGs, Authors, et = al.,

    I've found myself in the situation when two rela= ted drafts are in the WG APs in the SPRING and IPPM WG (with the possibilit= y that expertise from the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are c= losely related, I've decided to combine my questions and comments in a = single thread. I hope that would be acceptable and considered by the SPRING= WG as well as IPPM WG.

    Usually, the bar for the adoption of a document can = be evaluated=C2=A0by answers to these three questions:

    • Is the document(s) reasonably well-written

    I've got surprised that the drafts don't use= the terminology from RFC 4656 and 5357 and introduce their own terminology= for Session-Sender and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents withou= t proper definitions. Other than that both drafts are readable and reasonab= ly well-written.

    <RG> We are ok to change Sender to Session-Sender and Re= flector to Session-Reflector if it helps.

    =C2=A0

    GIM>> I believe that the consistency in terminology between the core = RFC and what is intended as its extension is not only helpful to a reader b= ut, to the best of my understanding, is required for IETF specifications. B= ut I don't think that switching the terminology will fix the fundamental issue with the proposal. The operation that is re= quired from the remote entity, whether it is referred to as responder or Se= ssion-Reflector, is not defined in Appendix I of RFC 5357, nor in RFCs 4656= or 5357 itself. In my opinion, the behavior required, as described in the draft, cannot be characterized = as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely n= ew protocol that, if there's a need in the new PM OAM protocol, must be= properly defined.

    =C2=A0 =C2=A0Gyan> I am in complete agreement wit= h Greg about terminology and consistency.=C2=A0 The problem with inconsiste= ncy is that that you are not following well known normative references required to understand the specification leading to confusion and misunder= standing of the specification.=C2=A0 The goal should be clear and concise i= n terminology and verbiage.

    <RG2> Agr= ee. Will address the terms from RFC 5357 in the next revision.

    <RG> There are many existing RFCs that use term =E2=80= =9CLink=E2=80=9D (e.g. RFC 5613, 5340, 8330, etc.) and term =E2=80=9CCongru= ent Path=E2=80=9D (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we c= an add a reference for them if it helps.

    GIM>> Thank you for listing these RFCs. I thin= k I need to clarify my questions. While a reference to any of RFCs you'= ve mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

    Now I'll try to illustrate my concern with using= the term "congruent path" in these drafts (using ASCII-art):<= /u>

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0\

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A----B=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E-----F

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 /

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0G------------H

    Consider an SR tunnel from A to F that traverses the= network as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definitio= n of "congruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and siz= e as the mirror image of the other", it looks as the path A-B-G-H-E-F = is congruent to that SR tunnel. But a packet of an active OAM intended to m= onitor a flow over the SR tunnel is out-of-band relative to that flow and will not produce any meaningful measurement. Of = course, for the case of the extensions in drafts *-twamp-srpm, direct loss = measurement can be performed, as information collected from node F and pack= ets that collect the counters are not required to be in-band with the monitored flow. So, this example, in m= y opinion, illustrates two of my concerns:

    =C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 using a congruent path for active performance measurement, e.g., TWA= MP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should= reflect the fundamental requirement of ensuring that active OAM test packets are in-band with the monitored fl= ow.

    =C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 there are no technical requirements to justify using in-band test pa= ckets for direct packet loss measurement. In fact, using the in-band method= for collecting in-profile counters leads to a waste of bandwidth, which ma= y have a negative impact on services that require low-latency and/or low packet loss. As demonstrated in this e= xample, direct packet loss can be performed using an out-of-band mechanism,= e.g., SNMP queries, Netconf notifications based on YANG data model.=

    • Does the document solve a real problem?

    No, it appears that these drafts define a new perfor= mance measurement protocol for the purpose of combining OWAMP and TWAMP fun= ctionality and adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technica= l arguments for using a PM protocol instead of, for example, extending the = existing OAM mechanisms like ICMP.

    =C2=A0Gyan> =C2=A0This may sound basic but is a v= ery critical subject going down the same lines of clarity in verbiage so th= eir is no misunderstanding. =C2=A0=E2=80=9CCongruent=E2=80=9D by definition= means shape of an object and if you super imposed two objects on top of each other the= y fit perfectly and the edges coincide identically.=C2=A0 The problem with = congruent is that it is based on the shape and that shape could be a mirror= image or reflection which may not be exact.=C2=A0 So when referring to a SR-TE path taken this could lead to co= nfusion as to path taken if it=E2=80=99s the same path or congruent which i= s vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here ther= e is criticality as to the path being referenced in terms of in-band versus out-of-band.=C2=A0 I agr= ee that for direct in band packet loss measurement can be done via existing= OAM mechanisme via ICMP.

    <RG2> Ok,= we will find an appropriate term for =E2=80=9Csending packets on the same = path as data traffic=E2=80=9D.

    <RG2> Ext= ending ICMP for direct-mode loss measurement is outside the scope of this d= raft. But good to see the agreement for the direct in band packet loss measurement to be done (albeit by some other means).=

    GIM2>> I feel that you misunderstand my positi= on in regard to the use case these four documents try to solve. I don't= recall that I've stated that "direct in-band packet loss measurem= ent" requires any additional standardization work. The Direct Measurement TLV has solved that for STAMP and draft-ietf-ippm-stamp= -option-tlv is now in the RFC Editor's queue. I cannot find any valid t= echnical reason to re-open this and measure the direct packet loss in a sli= ghtly different way. I must point out that a claim that using fixed positions for the direct packet loss optimiz= es performance does not stand for cases (Section 4.2.1 and 4.2.2 of draft-g= andhi-spring-stamp-srpm) when the return path is specified in the Return Pa= th TLV and, as I understand it, in some cases even the second TLV, Node Address TLV, is used. Thus, it is = clear that the proposed new method of direct packet loss measurement does n= ot offer any significant benefits comparing to the STAMP's Direct Measu= rement TLV and appears nothing but superfluous.

    =C2=A0

    <RG3> Th= e direct-mode packet loss use-case is typically for the forward direction p= acket loss. And this does not use the return path TLV. We can clarify that = in the draft.

    GIM3>>= ; Clarification would be very helpful as your latest note might be interpre= ted that the proposed mechanisms are not applicable in the case of a bi-dir= ectional SR tunnel.
    <= p class=3D"MsoNormal">

    <RG> There is a requirement to measure performance delay= as well as synthetic and direct-mode packet loss in segment-routing networ= ks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measur= ement today. I am not sure extending ICMP for LM is a good option here.

    GIM>> I agree with the=C2=A0requirements you've listed (though th= e=C2=A0SPRING WG OAM requirements document=C2=A0= has been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason=C2=A0to use OWAMP/TWAMP for exc= lusive direct packet loss measurement.=C2=A0=C2=A0

    =C2=A0 =C2=A0 Gyan> Agreed

    <RG2> There is definitely a n= eed to do direct-mode loss measurement in IP/SR networks, as RFC 6374 mecha= nisms are for MPLS networks. Note that there was an attempt to extend BFD f= or direct-mode loss measurement for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03)= .

    GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense. The work and discussion of= the proposal continues and the new version will be published soon.<= u>

    =C2=A0

    <RG3>= Ok, so you do see a need for the extensions for the direct-mode packet los= s detection and the authors are actively working on an alternate methods us= ing BFD. =C2=A0=C2=A0=

    • Is the proposed solution technically viable?

    There are too many unaddressed aspects, particularly= the risk introduced by the protocol on network security, to comprehensivel= y evaluate the proposed solution.

    <RG> Abou= t your comment on zero checksum, this is described in Security section in R= FC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

    GIM>> I don't think that a mere reference = sufficiently explains why the use of zero UDP checksum in IPv6 header is no= t decremental, does not create a security risk for the protocol.<= /u>

    =C2=A0=C2=A0 =C2=A0 Gyan> Agreed 0 UDP MIMA secur= ity threats and that you need to thorough vetting of RFC 6936.

    =C2=A0<RG2&g= t; Yes, will add in the next revision. Hope we can work together on needed = text.

    To summarize my review of=C2=A0these two drafts:<= /u>

    • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

    <RG> The = probe and response messages defined in [RFC 5357] are used for delay measur= ement and synthetic packet loss. The direct-mode packet loss messages are defined in draft-gandhi-ippm-twamp-srpm that match these delay measurement messages. As stated, draft-gandhi-= ippm-twamp-srpm defines =E2= =80=9Cextensions=E2=80=9D for TWAMP Light.

    GIM>> I cannot find where RFC 5357 defines "the probe and respon= se messages". Could you give a more specific reference or provide the = text that, in your opinion, defines such messages? But I'm more concern= ed with the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to BBF's=C2=A0TR-390, = I'm have learned how different are existing implementations of TWAMP Li= ght. And that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

    =C2=A0 Gyan> I don=E2=80=99t see the probe a d re= sponse messages in TWAMP RFC 5357=C2=A0

    <RG2> Agr= ee to use term test-packet from RFC 5357.

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 several parts of the proposed protocol, e.g., Z= ero UDP checksum in IPv6, require detailed security analysis, which is curr= ently absent;

    =C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

    <RG2> Ple= ase see previous reply.

    <RG> This= is specified in RFC 6936 Security Section. We will add reference to this R= FC in our Security Section as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

    GIM>>=C2=A0 I've noted above that a simple reference does not suf= ficiently explains why the use of zero UDP checksum in IPv6 header is not d= ecremental, does not create a security risk for the protocol. I believe tha= t the proposal to use zero UDP header checksum requires extensive analysis, using the analysis provided in RFC 6936.

    =C2=A0 =C2=A0 Gyan> Completely Agree

    =C2=A0<RG2&g= t; Please see previous reply.

    • I was surprised to find out that=C2=A0draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
    <RG> This was to address=
 your previous comment quoted as:=

     =E2=80=9C- as I understand, the draft is applicable t=
o TWAMP Light mode,

    =C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

    =C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

    =C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

    =C2=A0 track is more appropriate for th= is specification.=E2=80=9D

    https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

    <RG> Havi= ng said that, we are ok to change to PS.

    GIM>> As explained in RFC 8545 "TWAMP Light is an idea", no= t a protocol. If anyone is interested in standardizing an "extension&q= uot;, I'd expect that they first define the base specification to which= the extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Coul= d you point to the definition, for example, of the Authenticated mode in TW= AMP Light in the=C2=A0draft-gandhi-spring-twamp-srpm or RFC 5357?=C2=A0

    =C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

    <RG2> The= Appendix I of RFC 5357 does have information on the Authentication mode. A= s specified there, this is based on user configured parameters.

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 I believe that=C2=A0draft-gandhi-spring-twamp-s= rpm should be anchored at IPPM WG as it does introduce the new PM protocol.=

    <RG> The = TWAMP Light extension draft-gandhi-= ippm-twamp-srpm is already in IPPM WG. The SPRING draf= t only defines SR PM procedures.

    =C2=A0Below, please find my detailed=C2=A0comments, = questions on these drafts:

    • draft-gandhi-spring-twamp-srpm

    I have several questions about the relationships bet= ween this draft and Appendix I in RFC 5357 where the idea of a mode known a= s TWAMP Light has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained i= n Section 4 of=C2=A0RFC 8545=C2=A0(apologies for the long quote):

    =C2=A0 =C2=A0"TWAMP Light" is an idea desc= ribed in Appendix I ("TWAMP Light
    =C2=A0 =C2=A0(Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
    =C2=A0 =C2=A0control protocol combined with the TWAMP-Test protocol.=C2=A0 = In
    =C2=A0 =C2=A0[RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
    =C2=A0 =C2=A0TWAMP Light failed to meet the requirements for IETF protocols= (there
    =C2=A0 =C2=A0are no specifications for negotiating this form of operation a= nd no
    =C2=A0 =C2=A0specifications for mandatory-to-implement security features), = as
    =C2=A0 =C2=A0described in Appendix A of this memo.=C2=A0 See also [LarsAD] = and
    =C2=A0 =C2=A0[TimDISCUSS].

    =C2=A0 =C2=A0Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br> =C2=A0 =C2=A0component of TWAMP, it is considered reasonable for future sys= tems to
    =C2=A0 =C2=A0use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
    =C2=A0 =C2=A0is specified in this document).=C2=A0 Clearly, the TWAMP Light= idea
    =C2=A0 =C2=A0envisions many components and communication capabilities beyon= d
    =C2=A0 =C2=A0TWAMP-Test (implementing the security requirements, for exampl= e);
    =C2=A0 =C2=A0otherwise, Appendix I of [RFC5357] would be one sentence long<= br> =C2=A0 =C2=A0(equating TWAMP Light with TWAMP-Test only).

    =C2=A0Since we don't have an IETF document that = addressed these open questions, I don't think we can have a draft that = proposes extensions to a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.<= u>

    =C2=A0Gyan> Agreed=C2=A0

    <RG2> The= procedure for using the RFC 5357 defined messages in TWAMP Light configura= tion mode is defined in the corresponding spring drafts. It also describes the provisioning model.

    GIM2>> If a return path can be provisioned for= TWAMP Light, why the same method of controlling a test session cannot be u= sed for STAMP?

    =C2=A0

    <RG3> It= is not expected that all STAMP TLV extensions need to be supported for TWA= MP Light using provisioning.=C2=A0

    =

    =C2=A0<RG>= ; This was to address your previous comment quoted as<= /p> 

     =E2=80=9C- as I understand, the draft is applicable t=
o TWAMP Light mode,

    =C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

    =C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

    =C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

    =C2=A0=C2=A0 track is more appropriate = for this specification.=E2=80=9D

    https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

    <RG> Havi= ng said that, we are ok to change to PS as you mentioned above.

    <RG> BTW,= despite only difference of fixed vs. variable length payload in STAMP vs. = TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it uses the same approach of provisioning=C2=A0 as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

    GIM>> RFC 5357 mentioned TWAMP Light as an una= uthenticated, and thus the light, simpler, version of TWAMP-Test component = of TWAMP protocol. I cannot find in=C2=A0draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of TWAMP Light. Also, I'll prefer= not to refer to RFC 8762 STAMP in the discussion of "extension" = to TWAMP Light.

    <RG2> The= Authentication information is user-configured as shown in Section 3.1 of t= he draft-gandhi-spring-twamp-srpm, and is also described in Appendix I of RFC 5357.

    Now a number of more specific questions.

    draft-gandhi-spring-twamp-srpm:

    • In the Introduction it is stated that:

    =C2=A0 The TWAMP Light [Appendix I in RFC5357] [BBF.= TR-390] provides
    =C2=A0 =C2=A0simplified mechanisms for active performance measurement in Cu= stomer
    =C2=A0 =C2=A0IP networks by provisioning UDP paths and eliminates the need = for
    =C2=A0 =C2=A0control-channel signaling.

    I can not=C2=A0find where, either Appendix I or TR-3= 90, "eliminated the need for control-channel signaling". Also, co= uld you point where the referenced documents describe "provisioning UDP paths"?

    <RG> The Appendix I of R=
FC 5357 has following text. We can reword and match the exact text if you p=
refer.
    =C2=A0
    =E2=80=9CThis example eliminates the need for the TWAM=
P-Control protocol, and
    =C2=A0=C2=A0 assumes that the Session-Reflector is con=
figured=E2=80=9D

    GIM>> I think that the text you're proposi= ng is even more confusing. It is not clear which example the sentence is re= ferring to. Also, what is the basis for such an assumption?=C2=A0=

    <RG2> Thi= s is the exact text from RFC 5357 Appendix I. Please go through the entire = Section in that RFC 5357 to avoid =E2=80=9Cout of context=E2=80=9D discussi= on.

    • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

    =C2=A0 =C2=A0The procedure uses the mechanisms defin= ed in [RFC5357]
    =C2=A0 =C2=A0(TWAMP Light) and its extensions for Performance Measurement.<= u>

    I think that the reference must be to Appendix I, no= t RFC 5357. Also, could you please specify which extensions of TWAMP Light = have been used in this draft?

    <RG> We can add the Appendix I as reference in the next = revision. Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can ad= d this reference.

    GIM>> The problem, in my view, is that Appendi= x I of RFC 5357 must be a normative reference while it is, by its nature, a= n Informational document.=C2=A0=C2=A0

    <RG2> If = approved, it is fine to have informational draft/RFC in a normative referen= ce. But RFC 5357 is PS.

    • In Section 2.3 describing the reference model is noted:
      • <= /ul>

      =C2=A0 =C2=A0The probe response message is typically= sent to the sender node R1.

      In which scenarios the reflector acts differently? H= ow such behavior is related to the behavior of a TWAMP Session-Reflector, a= s defined in RFC 5357?

      <RG> Do you prefer we remove =E2=80=9Ctypically=E2=80=9D= from the sentence?

    GIM>> If that fits into the operational model = of the new protocol you're defining.=C2=A0

    • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

    <RG> Both= , please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known term used = in many existing RFCs (please see RFC 5613, 5340, 8330).

    GIM>> Thank you for the references. I couldn&#= 39;t find a definition of an object "Link" (capitalized) but only= "link" (lower case). Hence, since the draft consistently uses th= e capitalized form, I consider it to be something else, something different from a link.= =C2=A0

    <RG2> Ok,= we can change Link to link in the next revision to avoid confusion.=

    • In Section 3 behavior of the reflector described as

    =C2=A0 =C2=A0... no PM state for delay or loss measu= rement need to be created on the
    =C2=A0 =C2=A0reflector node R5.

    That is in contradiction to the behavior of a TWAMP = Session-Reflector as defined in RFC 5357. Could you provide a reference to = an IETF standard where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way= delay and synthetic loss measurement on a bidirectional SR tunnel?<= u>

    =C2=A0Gyan> Valid point=C2=A0

    <RG2> Bid= irectional SR tunnel may have an SR state but the statement above is that n= o PM (i.e. TWAMP Light) protocol session state is created for it. We can clarify in the next revision.

    GIM2>> So-called stateless Session-Reflector i= n TWAMP Light is only one option. I am well-familiar with the implementatio= n that uses the stateful mode.=C2=A0

    =C2=A0

    <RG3> Wh= at information stateful PM need to maintain in the state on the reflector? = Doesn=E2=80=99t that cause scale issues. We can add in the draft you if the= re is anything specifically needed in the spec.

    GIM3>> RFCs 5357 and 8762 are clear about what= information must be maintained by a Session-Reflector. The Session-Reflect= or must have knowledge of the test session state and count reflected test p= ackets. The value of such a counter must be copied in the Sequence Number f= ield of the reflected packet. Thus=C2=A0the method enables the measurement = of the one-way packet loss metric.
    =
    <= div>

    =

    =C2=A0<RG>= ; Quoting the text from Appendix I in RFC 5357. We can quote the text as is= .

    =E2=80=9CIn the case of TWAMP Light, the Session-Refle=
ctor does not necessarily have knowledge of the session state. =E2=80=9C

    GIM>> By the informational nature of Appendix = I, the text is not normative. I am familiar with the implementation of TWAM= P Light which does maintain the session state and thus supports one-way packet loss measurement. If you require that the remote node does = not maintain the state, the draft must define that as part of the specifyin= g the behavior of the protocol.

    =C2=A0<RG2&g= t; Ok, we can discuss what information is to be maintained in that state on= the reflector for synthetic packet loss. We can add appropriate text if you can help please.

    GIM2>> I don't see any reason to do that a= s that already defined in RFC 8762 and draft-ietf-ippm-stamp-yang=C2=A0

    =C2=A0

    <RG3> Ok= .=C2=A0

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Further, in Section 3 the selection of UDP port= explained as the following:

    =C2=A0 =C2=A0As specified in [RFC8545], the reflecto= r
    =C2=A0 =C2=A0supports the destination UDP port 862 for delay measurement pr= obe
    =C2=A0 =C2=A0messages by default.=C2=A0 This UDP port however, is not used = for loss
    =C2=A0 =C2=A0measurement probe messages.

    To the best of my understanding, as one of the contr= ibutors and=C2=A0Editors of RFC 8545, it re-allocated UDP port 862 for use = by a TWAMP Session-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in th= e same test session, using the same flow of TWAMP-Test packets.

    =C2=A0Gyan> Agreed=C2=A0

    <RG2> Yes= , we can use port 862 for both delay and synthetic packet loss =E2=80=93 th= ey are using the same test packet. There is no change proposed in the draft= .

    GIM2>> Packet delay and synthetic packet loss = measurements are already supported in RFC 8762. Are you proposing a new pro= tocol to duplicate the STAMP functionalities?

    =C2=A0

    <RG3> As= mentioned, the extensions defined are for the direct-mode packet loss meas= urement for TWAMP Light and STAMP.

    <RG> The = packet loss in existing RFC 5357 refers to synthetic loss as there is no su= pport for direct-mode loss in RFC 5357. We can change the text to clarify as =E2=80=9CThis UDP port however, is not used for direct-mode los= s measurement probe messages.=E2=80=9D

    GIM>> I've found that there's some mis= conception in the draft. RFC 8545 re-assigned UDP port 862 not for "de= lay measurement probe messages" but for TWAMP-Test protocol. TWAMP-Tes= t protocol, in turn, supports packet delay, packet loss, reordering (RFC 473= 7 defines packet reordering metric), and packet duplication measurement.=

    • Then the draft states that

    The sender uses the UDP port number following the gu= idelines specified in Section 6 in [RFC6335].

    Could you point to the guidelines that a user can us= e when selecting a UDP port number of a test session?

    Gyan> Good point =C2=A0

    <RG> Please see section 6 in [RFC6335]. We can cite the = range which will be the same as used in [RFC8762]. This was also discussed = earlier.

    https://mailarchive.ietf.= org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

    GIM>> I've looked through Section 6 but I = don't find anything specifically applicable to this draft we're dis= cussing. If the protocol to use UDP port numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it seems that stating that expli= citly would be the best way.=C2=A0

    <RG2> This would be, Use=
r Ports and Dynamic Ports ranges, which are defined in [RFC6335]. Yes, we can add this text.
    • At the closing of the paragraph, we read that

    =C2=A0 The number of UDP ports with PM functionality= needs to be minimized due
    =C2=A0 =C2=A0to limited hardware resources.

    Does a UDP port number pose PM functionality? How it= is assigned to the port number?

    <RG> UDP = ports are user configured for delay and direct-mode loss PM as described in= Section 3.1.

    GIM>> Can UDP port 862 be used? Also, requirin= g that the direct-loss measurement uses port number different from the one = used by a TWAMP-Test packet, in my opinion, is another indication that this is the definition of a different from TWAMP Light PM OAM protoco= l.=C2=A0

    <RG2> If = we add a field in the packet then UDP port 862 may be used along with the n= ew field. But it will require extra processing in hardware. It is better to use a different UDP port for processing efficiency in hardware.<= /span>

    • Following the above-quoted text, in Section 3 is noted:
      • <= /ul>

      =C2=A0 =C2=A0For Performance Measurement, probe quer= y and response messages are
      =C2=A0 =C2=A0sent as following:

      Could you clarify if the listed further procedures d= eviate from OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 53= 57 for Session-Sender and Session-Reflector respectively?

      <RG> Probe messages follow the same procedure as defined= in RFC 4656 and RFC 5357.

    GIM>> All messages, i.e., TWAMP-Test packets a= s well as the defined in=C2=A0draft-gandhi-ippm-twamp-srpm?=C2=A0=

    =C2=A0<RG2&g= t; Yes, unless otherwise specified in the draft-gandhi-ippm-twamp-srpm.

    • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

    =C2=A0 =C2=A0 =C2=A0 the probe messages are sent on = the
    =C2=A0 =C2=A0 =C2=A0 congruent path of the data traffic by the sender node<= u>

    It is not clear what "the congruent path" means. The definition o= f=C2=A0congruency in geometry tells us that an object B is congruent=C2=A0t= o object A if it has the same shape and size, but is allowed to flip, slide= or turn. How a path can be congruent to another path?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Agreed.=C2=A0 Th= e use of congruent in the context of pathing is confusing as the path being= addressed may not be reflected accurately by the term congruent.=

    <RG2> As = replied above.

    <RG> Ther= e are many existing RFCs that use term Congruent Path (e.g. RFC 5921, 6669)= without defining them. I suspect it is because it is well-known term. Having said that, we can add a reference for it if it helps reader.<= /span>

    GIM>> I cannot assume what was the context of = these RFCs. I've sketched a network diagram above to illustrate=C2=A0th= at a "congruent path" may well lead to out-of-band path. Is that the intention of the authors of the draft to use this protocol out-of-band= ?

    <RG2> As = replied above.

    • The last paragraph in Section 3 refers to work on iOAM:
      • <= /ul>

      =C2=A0 =C2=A0The In-Situ Operations, Administration,= and Maintenance (IOAM)
      =C2=A0 =C2=A0mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
      =C2=A0 =C2=A0SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
      =C2=A0 =C2=A0information such as timestamp in-band as part of the data pack= ets,
      =C2=A0 =C2=A0and are outside the scope of this document.

      Is iOAM in the scope of this specification? What are= the relationships between iOAM and=C2=A0draft-gandhi-spring-twamp-srpm?=

      <RG> As mentioned in the draft, IOAM is outside the scop= e.

    GIM>> Yes, but it appears that references to t= he two IOAM-related drafts have some purpose. What is it? How are these dra= fts related to=C2=A0draft-gandhi-spring-twamp-srpm?=C2=A0

    <RG2> We = can remove them if it is confusing. It is informational text (was added to = address a review comment).

    • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with=C2=A0draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?<= /u>

    <RG> Yes,= this can be Yang model. We can review draft-ietf-ippm-tw= amp-yang and add any missin= g items in a separate draft. We can also add a reference in this draft.

    GIM>> I think that theremust=C2=A0be some disc= ussion on how the new protocol is configured. If TWAMP YANG data model can = be augmented, I'd expect that being defined in=C2=A0draft-gandhi-ippm-t= wamp-srpm. But I couldn't find anything about the configuration of the protocol.= =C2=A0

    <RG2> The= Yang model extensions are not in the scope of this draft=C2=A0

    • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

    <RG> Exis= ting TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D loss measu= rement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clarify.

    GIM>> True, direct loss measurement, in fact, = is not active measurement and thus is outside the scope of Two-Way Active M= easurement Protocol (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, passive measurement method and fetching= counters can be done using numerous methods, e.g., SNMP, Netconf=C2=A0<= /u>

    <RG2> RFC= 7799 does not say using Test-packets to collect counters for direct-mod lo= ss measurement is passive.

    GIM2>> Per RFC 7799, injecting in-band test pa= ckets is the characteristic of an active measurement method. Using out-of-b= and transport, e.g., SNMP queries, would be an example of a passive measure= ment method.

    =C2=A0

    <RG3> Ok= , so you answered your own question that the direct-mode packet loss extens= ion defined is =E2=80=9Cactive measurement=E2=80=9D method.

    • Section 4.1.1 requires that

    =C2=A0 The Destination UDP port cannot be used as So= urce port, since
    =C2=A0 =C2=A0the message does not have any indication to distinguish betwee= n the
    =C2=A0 =C2=A0query and response message.

    Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Good question=C2= =A0

    <RG2> Yes= , it is unique in the domain.

    <RG> This= is user-defined and is up to the user what UDP port to provision in a doma= in.

    GIM>> So, can user configure a port number fro= m the User Ports range? Or, can the same port number be used on the same sy= stem for a number of test sessions? I find the use of UDP port numbers being underspecified.

    • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test pack= et in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test pa= cket format to perform both delay and packet loss measurement.

    <RG> Ok, = we can update the text in the next revision to indicate exact name from the= RFC 4656. We can also add text to include synthetic packet loss.=

    GIM>> I think that making it explicit would he= lp. Also, that will highlight what is being introduced by *twamp-srpm draft= s is, in fact, a new protocol to perform synthetic packet loss measurement.=C2=A0

    =C2=A0<RG2&g= t; No, it does not change anything for synthetic packet loss.=

    • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?=

    <RG> We c= an update the text in the next revision to indicate query format name from = RFC 5357.

    GIM>> I cannot find any reference to a query f= ormat in RFCs 4656/5357. Could you please quote from any of these documents= ?

    =C2=A0<RG2&g= t; It is test-packet, we will use RFC 5357 term.

    • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
    <RG> Yes. Please see sec=
tion 4.1.1 and quoted below:<=
u style=3D"font-family:monospace">
    =E2=80=9CFor symmetrical size query and response messa=
ges as defined in [RFC6038],=E2=80=9D

    GIM>> RFC 6038 defines an extension to RFC 535= 7 for OPTIONAL use of the symmetrical test packets. Since *-twamp-srpm prop= osals do not use TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about that either (in part because RFC 6038 came= later), I don't see that there's any certainty in what is the sze = of a test packet used in the direct-loss measurement.=C2=A0

    =C2=A0<RG2&g= t; The test-packets as defined in these existing RFCs are used for delay an= d synthetic packet loss. The direct-mode test-packets are defined in this draft.

    GIM2>> This draft defines only a new packet fo= rmat for the direct packet loss measurement. For STAMP such a mechanism is = clearly superfluous given the Direct Measurement TLV is already defined.=

    =C2=A0

    <RG3> As= replied earlier.

    • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

    <RG> This= is same as TWAMP. There is no change.

    GIM>> Per RFC 5357, TWAMP uses only NTP format= . Is that the case for *-twamp-srpm?=C2=A0

    =C2=A0<RG2&g= t; No change in existing in what is there in RFC 5357 and RFC 8186.<= u>

    • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

    <RG> Hard= ware timestamps are recommended for SR use-cases. We can change the sentenc= e.

    GIM>> Perhaps you can propose some text, that = would be helpful.=C2=A0

    =C2=A0<RG2&g= t; Ack.

    • Section 4.1.1.1 stated that

    =C2=A0 =C2=A0A separate user-configured
    =C2=A0 =C2=A0destination UDP port is used for the delay measurement in
    =C2=A0 =C2=A0authentication mode due to the different probe message format.=

    Can that be interpreted that there could be concurre= nt authenticated and unauthenticated test sessions using this protocol? Wou= ld different authentication methods require using unique destination UDP port numbers?

    <RG> Yes,= and Yes, and these are based on provisioning.

    GIM>> But that requirement is far outside the = TWAMP, as defined in RFC 5357.

    =C2=A0<RG2&g= t; Some Session-Sender can use authenticated and some not. It is part of RF= C 5357.

    • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

    <RG> The = direct-mode loss defines new procedure for sender/reflector to collect traf= fic counters, as opposed to timestamp. The rest is the same as RFC 4656 and 5357.

    GIM>> I cannot agree with your statement "= ; The rest is the same as RFC 4656 and 5357" because the sender's = direct-loss format does not have Error Estimate field, Thus, a reflected packet does not have Sender's Error Estimate, nor Error Estimate of th= e reflector. And that, in my opinion, is another clear indication that *twa= mp-srpm drafts define a new protocol, separate from OWAMP/TWAMP.<= /u>

    =C2=A0<RG2&g= t; That field is specific to timestamps and would not apply to counters for= direct-mode loss measurement.

    • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
    • A couple of question to the following text in Section 4.1.3:<= /li>

    =C2=A0 =C2=A0The local and remote IP
    =C2=A0 =C2=A0addresses of the link are used as Source and Destination Addre= sses.
    =C2=A0 =C2=A0They can also be IPv6 link local address as probe messages are= pre-
    =C2=A0 =C2=A0routed.

      • What are the addresses of a link?

    <RG> I am= assuming this well-known (e.g. RFC 2328).

    GIM>> I am not familiar with the term "pr= e-routed". What does it mean?=C2=A0

    =C2=A0<RG2&g= t; Ensure that packets are routed over the link.

      • In which scenarios an IPv6 LLA can be used?

    <RG> I am= assuming this is well-known (e.g. RFC 5613).

    GIM>> So, LLA may be used as the source and de= stination addresses when testing an SR tunnel?=C2=A0

    =C2=A0<RG2&g= t; As mentioned this is for links.

      • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such=C2=A0a=C2=A0packet will be routed, correct? That does appear as a security threat, would you agree= ?

    <RG> Abso= lutely do not agree. It is no different than IP routed TWAMP packet as defi= ned in [RFC5357].

    GIM>> You don't agree that the processing = described cannot happen because of laws of physics or it wouldn't happe= n because no one will think of that? If the latter, I think that that is security threat.

    =C2=A0<RG2&g= t; There is no new threat like you have mentioned.

    GIM2>> Hmmm, but how the integrity of TLVs pro= posed in=C2=A0draft-gandhi-ippm-stamp-srpm can=C2=A0be protected? These are= not protected by HMAC as presented in figures 3 and 5.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    =C2=A0

    <RG3> Th= e extensions do not change the processing of these existing TLVs defined fo= r HMAC. We can add text to indicate this.

    • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the= =C2=A0format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the tw= o is used for the delay measurement in the proposed protocol?=

    <RG> The = probe query packet in the Session-Sender text packet. We can update the nam= e.

    • Section 4.2.1 states that

    =C2=A0 =C2=A0In one-way measurement mode, the probe = response message as defined in
    =C2=A0 =C2=A0Figure 6 is sent back out-of-band to the sender node ...

    Could you clarify how the responder controls that th= e response packet is sent not in-band but out-of-band?

    <RG> Plea= se refer to section 3.1 in draft-gandhi-ippm-twamp-srpm.=C2=A0 This is exis= ting behaviour for out-of-band.

    GIM>>=C2=A0draft-gandhi-ippm-twamp-srpm does n= ot specify that it defines another new protocol OWAMP Light. And it is not = clear what you reference as "this is existing behavior". Is it to reference behavior of TWAMP test packet? But the behavior of the TWAMP-= Test protocol by itself is neither in-band, nor out-of-band. It is the enca= psulation of the TWAMP test packet that makes it either in-band or out-of-b= and.=C2=A0

    =C2=A0<RG2&g= t; Right.

    GIM>> So, you believe that proposing to use th= e method described in RFC 8403 for the TWAMP packet is innovation? And what= are the benefits of using the TWAMP test packet format in the Loopback mode?

    =C2=A0<RG2&g= t; Please see the draft.

    • What is the rationale for setting TTL/Hop Limit fields always to 255 for IP= v4, MPLS, and IPv6 (per Section 4.3.1)?

    <RG> This= is as defined in Section 4.2 of RFC 5357 (Bullet 4).<= /p>

    GIM>> I believe you've misunderstood the t= ext in RFC 5357. This bullet specifies the behavior of a Session-Reflector.= It is to try to read TTL value of the received TWAMP test packet and copy the value in Sender TTL field of the reflected packet. If the Ses= sion-Reflector cannot access the TTL field, it MUST write 255 in the Sender= TTL field. So, I think that my questions still remains.

    =C2=A0<RG2&g= t; Please see Section 4.2.1 of RFC 5357.

    • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be= lieve that allowing the use of Zero UDP checksum in some scenarios, this pr= otocol introduces a security threat that must be thoroughly analyzed in the= Security Considerations section.

    <RG> This= is described in RFC 6936. It will be very specific to the UDP port provisi= oned for TWAMP. We will add reference to RFC 6936 in Security Section.

    GIM>> I don't think that the reference is = sufficient for the Securit=C2=A0Consideration. I'd expect some extended= discussion on why using zero UDP header checksum is not a security threat for *twamp-srpm=C2=A0 protocol.

    =C2=A0<RG2&g= t; Please see reply above.

    • Section 8 refers to "liveness monitoring of Links and SR Paths". = This appears as the replication of functionality provided by BFD/S-BFD prot= ocols. Is such comparison accurate? If it is, shouldn't the proposal be= also reviewed by the BFD WG?

    <RG> TWAM= P=C2=A0 probe messages are used today for synthetic packet loss which can a= lso be used to detect connection loss (performance metric). The section simply highlights this obvious metric.

    GIM>> Can you point to a document that has def= ined "TWAMP=C2=A0 probe messages are used today for synthetic packet l= oss"? Also, which document defines loss of connectivity as a performan= ce metric? Does *twamp-srpm proposes to use the new protocol to detect the lo= ss of path continuity?

    =C2=A0<RG2&g= t; For example Y.1731 has such notion of connection loss. TWAMP is used wid= ely for synthetic packet loss and is well-known. There is no change in protocol. This is reported metric.

    GIM2>> What are packet transmission frequencie= s authors envisioned for that mode? A single-digit millisecond?=C2=A0

    =C2=A0

    <RG3> It= depends on the implementation.

    • I found the Security Section of the proposed protocol inadequately terse an= d missing very important threats that this protocol introduces in the netwo= rk.

    <RG> Othe= r than referring RFC 6936 for zero checksum what else is missing? Otherwise= it is no different than RFC 8762 (STAMP).

    GIM>> I cannot see how RFC 8762 is relevant to= *twamp-srpm drafts. The use of source IP addresses, as mentioned above, ap= pears to be another security risk introduced by *-twamp-srpm drafts.=C2=A0

    =C2=A0<RG2&g= t; There is no mention of Source IP address above.

    • draft-gandhi-ippm-twamp-srpm

    As I understand it, the motivation for the Loss Meas= urement mode defined in this specification is to collect "in-profile&q= uot; counters. Is that correct? Do you see as essential for this mode that the query messages are in-band with the flow being profiled= ? In your opinion, how using an out-of-band method of collecting these coun= ters, e.g., by using ICMP multi-part=C2=A0message extension per RFC 4884, c= ould affect the accuracy comparing with the method in this protocol? How the impact changes if extended ICMP messa= ges are in-band with the profiled flow?

    =C2=A0<RG2&g= t; Yes, they need to be in-band with the flow, to collect the counter from = the right forwarding paths for the flow. Discussion of using ICMP for direct-mode loss measurement is outside the scope of this draft.=

    GIM2>> I think that the assumption "they = need to be in-band with the flow, to collect the counter from the right for= warding paths for the flow" is technically inaccurate. Otherwise, how = SNMP queries could work for decades of networking history?

    =C2=A0

    --
    --0000000000002dce6a05b5b185f9-- From nobody Sat Dec 5 02:05:40 2020 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 947C83A10DC; Sat, 5 Dec 2020 02:05:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: ippm@ietf.org, last-call@ietf.org, draft-ietf-ippm-ioam-data.all@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160716273455.18414.13800286326641344283@ietfa.amsl.com> Reply-To: Dan Romascanu Date: Sat, 05 Dec 2020 02:05:34 -0800 Archived-At: Subject: [ippm] Genart last call review of draft-ietf-ippm-ioam-data-11 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 10:05:35 -0000 Reviewer: Dan Romascanu Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ippm-ioam-data-11 Reviewer: Dan Romascanu Review Date: 2020-12-05 IETF LC End Date: 2020-12-08 IESG Telechat date: Not scheduled for a telechat Summary: This is a very useful and rather complex document that discusses the data fields and associated data types for IOAM that can be encapsulated into a variety of protocols. It's well written, detailed and accurate. It is READY from a Gen-ART perspective, with a few editorial comments that I suggest being addressed before approval or as part of the final editorial process. Major issues: Minor issues: Nits/editorial comments: 1. How are specific IOAM encapsulations being defined? Will specifications that define IOAM encapsulations into various protocols be within the scope of the IPPM WG? of the IETF? Do they require to be RFCs? Some clarification text would be useful. 2. In Section 5.4.2.12 I found the following: > The authors acknowledge that in some operational cases there is a need for the units to be consistent across a packet path through the network, hence RECOMMEND the implementations to use standard units such as Bytes. 'The authors ... RECOMMEND' seems a little bit odd. The active verb form is not within the list of keywords as per [RFC2119], also mentioned in Section 3 of this document. To be on the safe side I would recommend reformulating the sentence so that the RECOMMENDED form is used. Alternatively, just do not use capitalization here. 3. In Section 8.7 I found: > The expert will post the request on the IPPM mailing list, and possibly on other relevant mailing lists, to allow for community feedback. I assume that this means the IPPM WG mailing list. The abbreviation of IPPM may be very familiar for the current audiences, but the situation may change in the future. The scope even of this document may outlive the WG. I suggest to expand IPPM in Section 3 and possibly reformulate the sentence so that posting the request on the IPPM list does not sound as the eternal procedure. From nobody Sat Dec 5 07:32:34 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AF43A0D79; Sat, 5 Dec 2020 07:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.59 X-Spam-Level: X-Spam-Status: No, score=-9.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=a4Xa7Jk7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aJjO4Y9t 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 oStTIfJEL9CJ; Sat, 5 Dec 2020 07:32:23 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257593A0D77; Sat, 5 Dec 2020 07:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=267497; q=dns/txt; s=iport; t=1607182343; x=1608391943; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VRmG7hChcT9FeXAwidFxehb+k22h9FUKBqZip4YQsb4=; b=a4Xa7Jk7r//X40YWEcDQJRnv4TrwSimQyAt4PQ8+HJL36tlFkIPEK3ZE 45cmP1bXoMKr4Azzaz/QiMk1Wdj3shRTyJ/dSxYsfLb5DFKsVoy3Qq+PA LeMTPpP3SaHBwKp1D4BTLdQubURk1gElg+BCRS5EKEvCG7gQ55L2JljAp A=; X-IPAS-Result: =?us-ascii?q?A0DjAgCkp8tfmJ1dJa2FXbwAJ0sFAQEBAwIDAQgDAgEGB?= =?us-ascii?q?BUBAQICjHw6hHa9B5Edgcx8GQ0?= IronPort-PHdr: =?us-ascii?q?9a23=3AsMP4MRUypPFZXAPH0TL7cwb6ULLV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyHuf1BguvS9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7dp3Sz6XgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,395,1599523200"; d="scan'208,217";a="628878818" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Dec 2020 15:32:22 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B5FWMBo028325 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 5 Dec 2020 15:32:22 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 5 Dec 2020 09:32:21 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 5 Dec 2020 09:32:20 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 5 Dec 2020 09:32:20 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jFrXv8G/fvQYgt+o/7bDPNQPBbjCR5TQ7FXzzdGQSeUdtSu/6K40JkKq6aFxuzw1T+iXj4IWgYZ4DGE/seix6BuUNK3GLv0ZAh+WCHg+QR8BHVhQV6ebWTXqZKOgD5eXNNlVAvg6LMk5v8LtEX+OAVMz6OnGV4wMr9GjJ7u1zRSqwIIO5A5byFU6JiHSlOFXVjldeTLBTwJ8G6xxzx7AGJ7/wd1FkvMae4+/VST3KELXuoB0mlwl4RXoez+dxHeqOS1q5tdtatB52JURgLF572+2nitfd39POThCral+6hc8IqcOnThjsivmw4haVmtamMsD4GaZii+zLy0uUT5XMQ== 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=QEGrav0GnBPORA+PdglAPHxWx9tbuUvQEg3Z1ALNxXY=; b=VuwqAyvyMT6tBx6S0JF5J34Q7lwsjWGM7Mk4ZB1/5YY8kVRWng7wx8ruNzhs8ICTgAXagboHF5/iTiYq+TXDC5muXMnBTSM9YDW3jrWE/lOWmx1nUx9jPvgjSscIAc/EUOqzXlTxd1DlazyMLqMtqcwUi+JtlHQY4Cczv3WShBwRQx0Ze05YAtFaMqmNWCOZPcuhNcfPg+XTk5n/a5stCAwdIp77qNYenJkpDov0QeYD8NdlJY9NN7+a4e/rd2t7FKanIeWnIUtMLyAIoFWaOlY/9mQOdnRhIcNAxAaC/f8d96NPKTSZW+knzfnUrDZ1C+Qa1ef8ibagYybm0plT+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QEGrav0GnBPORA+PdglAPHxWx9tbuUvQEg3Z1ALNxXY=; b=aJjO4Y9tQzAdMdtYz0LA99YXAUVWmiU5sKQS+3O4VCswD5qfp6LqMrm3Ycpyqp2Y3be6DQzGVQFX7dk143CqftnhS1C4mpWCZmyf5gg1oCZqObZgIy/4snB9ih3BOtsZFFfCdLlki/rEvAQ3KIWBcDRY17BL5TTLYGbr+i1VMxw= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM6PR11MB2873.namprd11.prod.outlook.com (2603:10b6:5:bd::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.31; Sat, 5 Dec 2020 15:32:18 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::b0:395a:1430:79d3]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::b0:395a:1430:79d3%5]) with mapi id 15.20.3632.021; Sat, 5 Dec 2020 15:32:18 +0000 From: "Rakesh Gandhi (rgandhi)" To: Gyan Mishra , Greg Mirsky CC: Greg Mirsky , IETF IPPM WG , James Guichard , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" Thread-Topic: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: AQHWw1FAi8Q0V5FtjUGdBFDHCBkgBqnZreOIgAc3iICAA1dl0YABdnSAgAJiHQCAAJSbyQ== Date: Sat, 5 Dec 2020 15:32:17 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fc76f171-407e-45f3-70d4-08d89932f341 x-ms-traffictypediagnostic: DM6PR11MB2873: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZVJ69++5hI6yIuCFnTZvBVoHle4QVaNU43hXNdVIEQa0l3P3I1JJFrWW6TXTW1TfKYU8Gz08T2O1KJS4N65lUXZ7tOblUxBV+pAUlcw3EKLUCYRkpYDlfqPi3oN9QvwWqA441G5dHeDoLduRydcuPN6ZrVbbcBjEmQMAtTROUjvBrvIMxpIw9kox9zCs0swOQAGmsfqTMHGOaAMHNhuvXGGTolxSmu+uIjDFqWtIY07jgtQ13nsaLk9Ztx7mapgz8+9DL/qVsMiR9/QxvuPchdpBqhlHwztz6c2ih07+ZWfFkjKJppA8picbtesnPJhGpWCA33suIW+zvuEYA2olNkMKKT4q6FANE7H13Ie5CLRi22gIBfsPxRT0IJ8YVYR/a398XNuK+e8HiljCGDPE6DvvB83epwOOkCY+qgdhteHWryEAUIb94gCRR//nyKSd x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(396003)(366004)(136003)(39860400002)(5660300002)(478600001)(8676002)(4326008)(52536014)(55016002)(8936002)(110136005)(6506007)(53546011)(54906003)(966005)(83380400001)(66476007)(316002)(76116006)(66446008)(64756008)(66556008)(91956017)(86362001)(26005)(66946007)(30864003)(9686003)(7696005)(71200400001)(186003)(33656002)(2906002)(166002)(9326002)(579004)(559001)(569008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?Xc8KSzgJb+a5STvTax/ePo1IvcXEnL2eLWdfPdl+d8oSnq8mw08WMh98?= =?Windows-1252?Q?7paXJgu8xEYjYOkFevpYJbx6LH2Swyo9lbBV/ExPzaN5LyktyOTBub8a?= =?Windows-1252?Q?HYhvVMldeC3DoI296Ktf3i71lurcb+SOL8HvhmYYimREBLyXS6840pPj?= =?Windows-1252?Q?ybOz7sbcx3OhDVvsZTmwzozZHhHJFhrHvn+6J9OW3yjSrp3KgcjJYsZ6?= =?Windows-1252?Q?IIl6BtNb2+3RdI2YvzZw+G/yylWpa19RI+F3B/TTX2Dj3k9qM7/1+3Fe?= =?Windows-1252?Q?BFet0oYyBAhi1Hnzf6uOzyFmFbbv2JOGafnr/M0b6UR4bFEO+xO3PsH/?= =?Windows-1252?Q?uI+XEdftfvOIV1W5DQ+x/MiVq20QqXbDwx/N/PMbyTBM7Yc/+H5bD6Fm?= =?Windows-1252?Q?OMqwpw/cJzXSIUicKgUGmGg2JpHodVplIBgH9oRPQF1e52UJd26rZncT?= =?Windows-1252?Q?QtqJfi7l9UMYHNkPRMj41YYlc6macAt7OEBWvlFvLqtNaiK0/eqOo2er?= =?Windows-1252?Q?CkUrKX4S5jDimc/u9OLA5YYGMXkXpQ9BsF1gABWHwXZ+v5UrmhN5SHuF?= =?Windows-1252?Q?jwb0tm9OWs9d8eFG1GdTjwogNjaLpDWTzQSHCFVz9JA84NXGza/JDLKE?= =?Windows-1252?Q?4n3Xgb7ZSdFJzF9MEmRr9cjPuUqZGdiXqEawIa4VA9FTGeQothd7rr+5?= =?Windows-1252?Q?anMM0p0ThtPi/Dnmh6RoJVkgQbRq6vF0133FaCDK0J6nE6IMLu8LhvKl?= =?Windows-1252?Q?VNALsJIXYx2+vT0eMTz5y5FRr1epChGOQN+pAqfeqlb2nnAt9Xgb+2Px?= =?Windows-1252?Q?+Et8Cm5dfAfBFmKX6R+yKZ8WSzm7G1f30wXH5CIgXDx1z2vb1ieBjfC0?= =?Windows-1252?Q?jTab8dDNUEa99GR3Zx/UrXKg7lqsbDXa47YiXhXc5VNz/hfxqxghwIG9?= =?Windows-1252?Q?Q5CnaCMTmAC4AtXqxAddPAaLTVpbPb965MjSFmM10+OS4+yI0IAuMn57?= =?Windows-1252?Q?fwwyFiASjJP++oDUkiSuNyZ1AlklAbRpLQFGqFm6h3pgbJHqfBz68MnF?= =?Windows-1252?Q?q+fFroMs51eeKIxjenNy4dXgNHApfalKQ3UVug=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3115AA86AEB65611AFE973A4BFF00DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc76f171-407e-45f3-70d4-08d89932f341 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2020 15:32:18.0062 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hzK/SqxoREhVJLPvNqU9gXAJDou/Mn1TlqFO74cwOXP0Jt56+/WznIIcekfCN1iB0edwV3aRCHbg2XC3x5zElg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2873 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 15:32:32 -0000 --_000_DM6PR11MB3115AA86AEB65611AFE973A4BFF00DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gyan, Thanks for your review comments. Please see inline with =85 From: Gyan Mishra Date: Saturday, December 5, 2020 at 1:16 AM To: Greg Mirsky Cc: Greg Mirsky , IETF IPPM WG , J= ames Guichard , Rakesh Gandhi (rgandhi) , ippm-chairs@ietf.org , spring-chair= s@ietf.org , spring@ietf.org Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Hi Rakesh Had a general question. I read through the draft again and a question came to mind as this draft is= Standards Track, what new is being introduced other then a procedure of ho= w to use TWAMP in SR networks SR-MPLS which reuses the MPLS data plane and = SRv6 which used the IPv6 data plane. I don=92t believe there exists a Sta= ndards track draft procedure for how to use STAMP over IP network or MPLS n= etwork as an example. Section 4.1.4 describes SR-MPLS use case and SRv6 use case. As there appea= rs to be nothing new introduced such as a new IANA TLV or code point or eve= n a special SID code point for TWAMP, all basic vanilla SR, that without t= his draft you could run STAMP, TWAMP, OWAMP over SR which has existed for a= while now. What is the new invention here? SPRING drafts define the procedure for using TWAMP Light and STAMP te= st-messages for SR path and links. The corresponding IPPM drafts define the= extensions needed for them. The SPRING drafts also use the extensions for = them defined in the corresponding IPPM drafts. The extensions are needed fo= r (1) in-band response request e.g. for two-way mode for links and SR path,= (2) Return path for SR e.g. when using bidirectional SR Path, and (3) for = collecting TX and RX traffic counters in-band for direct-mode loss measurem= ent. Sorry but I may have missed something. My thoughts are at most this be a BCP or I am thinking informational draft = would be appropriate. Given above context, if WG thinks that any of the drafts should be BC= P or Informational or Experimental, we can update the draft accordingly. Thoughts? Gyan On Thu, Dec 3, 2020 at 12:51 PM Greg Mirsky > wrote: Hi Rakesh, thank you for the continued discussion. You can find my follow-up notes in-= line below under GIM3>> tag. I felt that one comment is at the root of our = different views on what is considered to be a problem that drafts solve. Yo= u've said: As mentioned, the extensions defined are for the direct-mode packet l= oss measurement for TWAMP Light and STAMP. But draft-ietf-ippm-stamp-option-tlv, currently in Submitted to IESG for Publicat= ion WG state according to IETF datatracker, includes Section 4.5 Direct Mea= surement TLV. It is noted in the section: The Direct Measurement TLV enables collection of the number of in- profile packets, i.e., packets that form a specific data flow, that had been transmitted and received by the Session-Sender and Session- Reflector, respectively. The definition of "in-profile packet" is outside the scope of this document and is left to the test operators to determine. Hi Greg, The motivation has been there in the draft-gandhi-ippm-stamp-srpm, Section = 1. Copied below for the convenience. The STAMP message with a TLV for "direct measurement" can be used for combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. However, in order to use only for loss measurement purpose, it requires the node to support the delay measurement messages and support timestamp for these messages (which may also require clock synchronization). Furthermore, for hardware-based counter collection for direct-mode loss measurement, the optional TLV based processing adds unnecessary overhead (as counters are not at well-known locations). Thus I cannot see any technical need for the introduction of yet another wa= y of direct loss measurement in STAMP. As for the case of TWAMP Light, I be= lieve that there's no sufficient evidence that the proposed direct loss-mea= surement measurement method benefits existing implementations of TWAMP Ligh= t. Also, historically, all extensions applicable to TWAMP Light have been i= ntroduced through extending TWAMP proper, i.e., extending TWAMP-Control and= TWAMP-Test. The way of "extending" TWAMP Light presented in the drafts we = are discussing is, in my opinion, in violation of RFC 5357. The IPPM WG Informational draft on TWAMP Light direct-mode loss measu= rement, defines the message format and corresponding SPRING draft defines t= he procedure for using that. It is not clear to me how providing an informa= tional draft gandhi-ippm-twamp-srpm is violating RFC 5357. Thanks, Rakesh More notes can be found below. Regards, Greg On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for your further reply and the discussions. Good to know that you do see a need for the extensions for the direct-mode = packet loss detection and the authors are actively working on an alternate = methods using BFD (as you mentioned below). GIM3>> As you've recognized, in draft-mirmin-bfd-extended we build an integrated OAM= based on the lightweight Fault Management protocol with optional Performan= ce Monitoring, based on RFC 6374. RFC 6374, in turn, provides a rich set of= performance measurement methods, including direct loss measurement. Please see replies inline with =85. From: Greg Mirsky > Date: Monday, November 30, 2020 at 11:30 AM To: Rakesh Gandhi (rgandhi) > Cc: Gyan Mishra >, IETF= IPPM WG >, James Guichard >, ippm-chairs@ie= tf.org >, spring-chairs@ietf.org >, spring@ietf.org >, Greg Mirsky > Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Hi Rakesh, thank you for the continued discussion. I appreciate your responses. I am s= till not convinced of the value these documents add. Please find my follow-= up notes in-line below under the GIM2>> tag. Regards, Greg On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) > wrote: Thank you Gyan and Greg for your review comments and discussions. Please se= e inline replies with =85 From: Gyan Mishra > Date: Wednesday, November 25, 2020 at 12:34 PM To: Greg Mirsky > Cc: IETF IPPM WG >, James Guichard >, Rakesh= Gandhi (rgandhi) >, ippm-chair= s@ietf.org >, spring-chairs@ietf.org >, spring@ietf.org > Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Hi Rakesh I have been following this thread and to help progress the discussion I wou= ld like to provide some comments in-line Gyan> Thanks Gyan On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky > wrote: Hi Rakesh, thank you for the response to my comments. Please find my follow-up notes i= n-lined below under the GIM>> tag. Regards, Greg On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Please see replies inline with =85 From: ippm > Date: Friday, November 6, 2020 at 11:18 AM To: James Guichard > Cc: spring@ietf.org >, ippm-chairs@ietf.org >, spring-chairs@ietf.org >,= IETF IPPM WG > Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Dear Chairs of the SPRING and IPPM WGs, Authors, et al., I've found myself in the situation when two related drafts are in the WG AP= s in the SPRING and IPPM WG (with the possibility that expertise from the t= hird WG, BFD WG, might be desirable to review the "liveness monitoring"). B= ecause these drafts are closely related, I've decided to combine my questio= ns and comments in a single thread. I hope that would be acceptable and con= sidered by the SPRING WG as well as IPPM WG. Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: * Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFC 4656 = and 5357 and introduce their own terminology for Session-Sender and Session= -Reflector. Also, many terms, e.g., Links, "congruent paths", are used in t= he documents without proper definitions. Other than that both drafts are re= adable and reasonably well-written. We are ok to change Sender to Session-Sender and Reflector to Session-= Reflector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. But I d= on't think that switching the terminology will fix the fundamental issue wi= th the proposal. The operation that is required from the remote entity, whe= ther it is referred to as responder or Session-Reflector, is not defined in= Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion, th= e behavior required, as described in the draft, cannot be characterized as = an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely new = protocol that, if there's a need in the new PM OAM protocol, must be proper= ly defined. Gyan> I am in complete agreement with Greg about terminology and consist= ency. The problem with inconsistency is that that you are not following we= ll known normative references required to understand the specification lead= ing to confusion and misunderstanding of the specification. The goal shoul= d be clear and concise in terminology and verbiage. Agree. Will address the terms from RFC 5357 in the next revision. There are many existing RFCs that use term =93Link=94 (e.g. RFC 5613, = 5340, 8330, etc.) and term =93Congruent Path=94 (e.g. RFC 5921, 6669) witho= ut defining them. I suspect it is because these are well-known terms. Havin= g said that, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . Is A-B-G-H-E-F congruent to it? From the definition of "congruent" as "tw= o figures or objects are congruent if they have the same shape and size, or= if one has the same shape and size as the mirror image of the other", it l= ooks as the path A-B-G-H-E-F is congruent to that SR tunnel. But a packet o= f an active OAM intended to monitor a flow over the SR tunnel is out-of-ban= d relative to that flow and will not produce any meaningful measurement. Of= course, for the case of the extensions in drafts *-twamp-srpm, direct loss= measurement can be performed, as information collected from node F and pac= kets that collect the counters are not required to be in-band with the moni= tored flow. So, this example, in my opinion, illustrates two of my concerns= : =95 using a congruent path for active performance measurement, e.g.= , TWAMP or TWAMP Light, may produce information that does not reflect the c= ondition experienced by the monitored flow. It seems that the terminology s= hould reflect the fundamental requirement of ensuring that active OAM test = packets are in-band with the monitored flow. =95 there are no technical requirements to justify using in-band te= st packets for direct packet loss measurement. In fact, using the in-band m= ethod for collecting in-profile counters leads to a waste of bandwidth, whi= ch may have a negative impact on services that require low-latency and/or l= ow packet loss. As demonstrated in this example, direct packet loss can be = performed using an out-of-band mechanism, e.g., SNMP queries, Netconf notif= ications based on YANG data model. * Does the document solve a real problem? No, it appears that these drafts define a new performance measurement proto= col for the purpose of combining OWAMP and TWAMP functionality and adding t= he ability to collect counters of "in-profile" packets. I couldn't find suf= ficient technical arguments for using a PM protocol instead of, for example= , extending the existing OAM mechanisms like ICMP. Gyan> This may sound basic but is a very critical subject going down the = same lines of clarity in verbiage so their is no misunderstanding. =93Cong= ruent=94 by definition means shape of an object and if you super imposed tw= o objects on top of each other they fit perfectly and the edges coincide id= entically. The problem with congruent is that it is based on the shape and= that shape could be a mirror image or reflection which may not be exact. = So when referring to a SR-TE path taken this could lead to confusion as to = path taken if it=92s the same path or congruent which is vague as to =93exa= ctly=94 which path is taken where here there is criticality as to the path = being referenced in terms of in-band versus out-of-band. I agree that for = direct in band packet loss measurement can be done via existing OAM mechani= sme via ICMP. Ok, we will find an appropriate term for =93sending packets on the sa= me path as data traffic=94. Extending ICMP for direct-mode loss measurement is outside the scope = of this draft. But good to see the agreement for the direct in band packet = loss measurement to be done (albeit by some other means). GIM2>> I feel that you misunderstand my position in regard to the use case = these four documents try to solve. I don't recall that I've stated that "di= rect in-band packet loss measurement" requires any additional standardizati= on work. The Direct Measurement TLV has solved that for STAMP and draft-iet= f-ippm-stamp-option-tlv is now in the RFC Editor's queue. I cannot find any= valid technical reason to re-open this and measure the direct packet loss = in a slightly different way. I must point out that a claim that using fixed= positions for the direct packet loss optimizes performance does not stand = for cases (Section 4.2.1 and 4.2.2 of draft-gandhi-spring-stamp-srpm) when = the return path is specified in the Return Path TLV and, as I understand it= , in some cases even the second TLV, Node Address TLV, is used. Thus, it is= clear that the proposed new method of direct packet loss measurement does = not offer any significant benefits comparing to the STAMP's Direct Measurem= ent TLV and appears nothing but superfluous. The direct-mode packet loss use-case is typically for the forward dir= ection packet loss. And this does not use the return path TLV. We can clari= fy that in the draft. GIM3>> Clarification would be very helpful as your latest note might be int= erpreted that the proposed mechanisms are not applicable in the case of a b= i-directional SR tunnel. There is a requirement to measure performance delay as well as synthet= ic and direct-mode packet loss in segment-routing networks. OWAMP and TWAMP= protocols are widely deployed for performance delay and synthetic packet l= oss measurement today. I am not sure extending ICMP for LM is a good option= here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP for exclusive = direct packet loss measurement. Gyan> Agreed There is definitely a need to do direct-mode loss measurement in IP/S= R networks, as RFC 6374 mechanisms are for MPLS networks. Note that there w= as an attempt to extend BFD for direct-mode loss measurement for this purpo= se using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-0= 3). GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense.= The work and discussion of the proposal continues and the new version will= be published soon. Ok, so you do see a need for the extensions for the direct-mode packe= t loss detection and the authors are actively working on an alternate metho= ds using BFD. * Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocol on network security, to comprehensively evaluate the proposed= solution. About your comment on zero checksum, this is described in Security sec= tion in RFC 6936. We will add reference to this RFC in our Security Section= as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Gyan> Agreed 0 UDP MIMA security threats and that you need to thorough= vetting of RFC 6936. Yes, will add in the next revision. Hope we can work together on nee= ded text. To summarize my review of these two drafts: * these propose a new protocol, not an update or enhancement of the TWA= MP-like protocol; The probe and response messages defined in [RFC 5357] are used for del= ay measurement and synthetic packet loss. The direct-mode packet loss messa= ges are defined in draft-gandhi-ippm-twamp-srpm that match these delay measurement mes= sages. As stated, draft-gandhi-ippm-twamp-srpm defines =93extensions=94 for TWAMP Ligh= t. GIM>> I cannot find where RFC 5357 defines "the probe and response messages= ". Could you give a more specific reference or provide the text that, in yo= ur opinion, defines such messages? But I'm more concerned with the directio= n of "extending" non-protocol referred to as "TWAMP Light". As a contributo= r to BBF's TR-390, I'm have learned how different are existing implementati= ons of TWAMP Light. And that is also noted in EANTC Multi-Vendor Interopera= bility 2019 white paper. The status of TWAMP Light is explain= ed in RFC 8545 and I cannot see that it can be used as a foundation of any = standard. Gyan> I don=92t see the probe a d response messages in TWAMP RFC 5357 Agree to use term test-packet from RFC 5357. =95 several parts of the proposed protocol, e.g., Zero UDP checksum= in IPv6, require detailed security analysis, which is currently absent; Gyan> Agreed Please see previous reply. This is specified in RFC 6936 Security Section. We will add reference = to this RFC in our Security Section as well. This is only specific to the U= DP port locally provisioned in the domain by the operator for TWAMP. GIM>> I've noted above that a simple reference does not sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol. I believe that the proposal = to use zero UDP header checksum requires extensive analysis, using the anal= ysis provided in RFC 6936. Gyan> Completely Agree Please see previous reply. * I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on t= he Informational track even though it is essential to the new protocol as i= t defines its key elements This was to address your previous comment quoted as: =93- as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea is described in the informational text only, I think that the Informational track is more appropriate for this specification.=94 https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ Having said that, we are ok to change to PS. GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. If= anyone is interested in standardizing an "extension", I'd expect that they= first define the base specification to which the extension applies. I migh= t have missed the definition of TWAMP Light protocol in the draft. Could yo= u point to the definition, for example, of the Authenticated mode in TWAMP = Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? Gyan> Agreed The Appendix I of RFC 5357 does have information on the Authenticatio= n mode. As specified there, this is based on user configured parameters. =95 I believe that draft-gandhi-spring-twamp-srpm should be anchore= d at IPPM WG as it does introduce the new PM protocol. The TWAMP Light extension draft-gandhi-ippm-twamp-srpm is already in IPPM WG. The= SPRING draft only defines SR PM procedures. Below, please find my detailed comments, questions on these drafts: * draft-gandhi-spring-twamp-srpm I have several questions about the relationships between this draft and App= endix I in RFC 5357 where the idea of a mode known as TWAMP Light has been = mentioned. The nature of the TWAMP Light and what is required to make it a = standard is well-explained in Section 4 of RFC 8545 (apologies for the long quote): "TWAMP Light" is an idea described in Appendix I ("TWAMP Light (Informative)") of [RFC5357]; TWAMP Light includes an unspecified control protocol combined with the TWAMP-Test protocol. In [RFC5357], the TWAMP Light idea was relegated to Appendix I because TWAMP Light failed to meet the requirements for IETF protocols (there are no specifications for negotiating this form of operation and no specifications for mandatory-to-implement security features), as described in Appendix A of this memo. See also [LarsAD] and [TimDISCUSS]. Since the idea of TWAMP Light clearly includes the TWAMP-Test component of TWAMP, it is considered reasonable for future systems to use the TWAMP-Test well-known UDP port (whose reallocated assignment is specified in this document). Clearly, the TWAMP Light idea envisions many components and communication capabilities beyond TWAMP-Test (implementing the security requirements, for example); otherwise, Appendix I of [RFC5357] would be one sentence long (equating TWAMP Light with TWAMP-Test only). Since we don't have an IETF document that addressed these open questions, = I don't think we can have a draft that proposes extensions to a non-standar= d mechanism (Appendix is for Informational material, as I understand it) on= the Standard track. Gyan> Agreed The procedure for using the RFC 5357 defined messages in TWAMP Light = configuration mode is defined in the corresponding spring drafts. It also d= escribes the provisioning model. GIM2>> If a return path can be provisioned for TWAMP Light, why the same me= thod of controlling a test session cannot be used for STAMP? It is not expected that all STAMP TLV extensions need to be supported= for TWAMP Light using provisioning. This was to address your previous comment quoted as =93- as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea is described in the informational text only, I think that the Informational track is more appropriate for this specification.=94 https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ Having said that, we are ok to change to PS as you mentioned above. BTW, despite only difference of fixed vs. variable length payload in S= TAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it = uses the same approach of provisioning as defined in this draft). Hence, s= ecurity considerations for STAMP and TWAMP Light are not different. Note th= at both STAMP and TWAMP Light have authenticated messages defined for Secur= ity purpose. GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the li= ght, simpler, version of TWAMP-Test component of TWAMP protocol. I cannot f= ind in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode = of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the dis= cussion of "extension" to TWAMP Light. The Authentication information is user-configured as shown in Section= 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described in Append= ix I of RFC 5357. Now a number of more specific questions. draft-gandhi-spring-twamp-srpm: * In the Introduction it is stated that: The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides simplified mechanisms for active performance measurement in Customer IP networks by provisioning UDP paths and eliminates the need for control-channel signaling. I can not find where, either Appendix I or TR-390, "eliminated the need for= control-channel signaling". Also, could you point where the referenced doc= uments describe "provisioning UDP paths"? The Appendix I of RFC 5357 has following text. We can reword and match= the exact text if you prefer. =93This example eliminates the need for the TWAMP-Control protocol, and assumes that the Session-Reflector is configured=94 GIM>> I think that the text you're proposing is even more confusing. It is = not clear which example the sentence is referring to. Also, what is the bas= is for such an assumption? This is the exact text from RFC 5357 Appendix I. Please go through th= e entire Section in that RFC 5357 to avoid =93out of context=94 discussion. * It appears that the last paragraph in the Introduction describes the = relationship with Appendix I of RFC 5357: The procedure uses the mechanisms defined in [RFC5357] (TWAMP Light) and its extensions for Performance Measurement. I think that the reference must be to Appendix I, not RFC 5357. Also, could= you please specify which extensions of TWAMP Light have been used in this = draft? We can add the Appendix I as reference in the next revision. Extension= s are defined in draft-gandhi-ippm-twamp-srpm, we can add this reference. GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a nor= mative reference while it is, by its nature, an Informational document. If approved, it is fine to have informational draft/RFC in a normativ= e reference. But RFC 5357 is PS. * In Section 2.3 describing the reference model is noted: The probe response message is typically sent to the sender node R1. In which scenarios the reflector acts differently? How such behavior is rel= ated to the behavior of a TWAMP Session-Reflector, as defined in RFC 5357? Do you prefer we remove =93typically=94 from the sentence? GIM>> If that fits into the operational model of the new protocol you're de= fining. * Also in Section 2.3 a Link is mentioned as an element directly connec= ting nodes in the presented reference model. Could you clarify what is a Li= nk? Is it always a physical connection between two systems or a virtual? Both, please see Section 4.1.3. =93Link=94 is well known term used in = many existing RFCs (please see RFC 5613, 5340, 8330). GIM>> Thank you for the references. I couldn't find a definition of an obje= ct "Link" (capitalized) but only "link" (lower case). Hence, since the draf= t consistently uses the capitalized form, I consider it to be something els= e, something different from a link. Ok, we can change Link to link in the next revision to avoid confusio= n. * In Section 3 behavior of the reflector described as ... no PM state for delay or loss measurement need to be created on the reflector node R5. That is in contradiction to the behavior of a TWAMP Session-Reflector as de= fined in RFC 5357. Could you provide a reference to an IETF standard where = this behavior is defined? Also, how, without creating a state at the Sessio= n-Reflector, to achieve one-way delay and synthetic loss measurement on a b= idirectional SR tunnel? Gyan> Valid point Bidirectional SR tunnel may have an SR state but the statement above = is that no PM (i.e. TWAMP Light) protocol session state is created for it. = We can clarify in the next revision. GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one opt= ion. I am well-familiar with the implementation that uses the stateful mode= . What information stateful PM need to maintain in the state on the ref= lector? Doesn=92t that cause scale issues. We can add in the draft you if t= here is anything specifically needed in the spec. GIM3>> RFCs 5357 and 8762 are clear about what information must be maintain= ed by a Session-Reflector. The Session-Reflector must have knowledge of the= test session state and count reflected test packets. The value of such a c= ounter must be copied in the Sequence Number field of the reflected packet.= Thus the method enables the measurement of the one-way packet loss metric. Quoting the text from Appendix I in RFC 5357. We can quote the text a= s is. =93In the case of TWAMP Light, the Session-Reflector does not necessarily h= ave knowledge of the session state. =93 GIM>> By the informational nature of Appendix I, the text is not normative.= I am familiar with the implementation of TWAMP Light which does maintain t= he session state and thus supports one-way packet loss measurement. If you = require that the remote node does not maintain the state, the draft must de= fine that as part of the specifying the behavior of the protocol. Ok, we can discuss what information is to be maintained in that stat= e on the reflector for synthetic packet loss. We can add appropriate text i= f you can help please. GIM2>> I don't see any reason to do that as that already defined in RFC 876= 2 and draft-ietf-ippm-stamp-yang Ok. =95 Further, in Section 3 the selection of UDP port explained as th= e following: As specified in [RFC8545], the reflector supports the destination UDP port 862 for delay measurement probe messages by default. This UDP port however, is not used for loss measurement probe messages. To the best of my understanding, as one of the contributors and Editors of = RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflector= without excluding any type of measurement. Besides, in TWAMP delay and pac= ket loss are measured in the same test session, using the same flow of TWAM= P-Test packets. Gyan> Agreed Yes, we can use port 862 for both delay and synthetic packet loss =96= they are using the same test packet. There is no change proposed in the dr= aft. GIM2>> Packet delay and synthetic packet loss measurements are already supp= orted in RFC 8762. Are you proposing a new protocol to duplicate the STAMP = functionalities? As mentioned, the extensions defined are for the direct-mode packet l= oss measurement for TWAMP Light and STAMP. The packet loss in existing RFC 5357 refers to synthetic loss as there= is no support for direct-mode loss in RFC 5357. We can change the text to = clarify as =93This UDP port however, is not used for direct-mode loss measu= rement probe messages.=94 GIM>> I've found that there's some misconception in the draft. RFC 8545 re-= assigned UDP port 862 not for "delay measurement probe messages" but for TW= AMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, pac= ket loss, reordering (RFC 4737 defines packet reordering metric), and packe= t duplication measurement. * Then the draft states that The sender uses the UDP port number following the guidelines specified in S= ection 6 in [RFC6335]. Could you point to the guidelines that a user can use when selecting a UDP = port number of a test session? Gyan> Good point Please see section 6 in [RFC6335]. We can cite the range which will be= the same as used in [RFC8762]. This was also discussed earlier. https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ GIM>> I've looked through Section 6 but I don't find anything specifically = applicable to this draft we're discussing. If the protocol to use UDP port = numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it= seems that stating that explicitly would be the best way. This would be, User Ports and Dynamic Ports ranges, which are defined= in [RFC6335]. Yes, we can add this te= xt. * At the closing of the paragraph, we read that The number of UDP ports with PM functionality needs to be minimized due to limited hardware resources. Does a UDP port number pose PM functionality? How it is assigned to the por= t number? UDP ports are user configured for delay and direct-mode loss PM as des= cribed in Section 3.1. GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss measur= ement uses port number different from the one used by a TWAMP-Test packet, = in my opinion, is another indication that this is the definition of a diffe= rent from TWAMP Light PM OAM protocol. If we add a field in the packet then UDP port 862 may be used along w= ith the new field. But it will require extra processing in hardware. It is = better to use a different UDP port for processing efficiency in hardware. * Following the above-quoted text, in Section 3 is noted: For Performance Measurement, probe query and response messages are sent as following: Could you clarify if the listed further procedures deviate from OWAMP/TWAMP= or follow procedures defined in RFC 4656 and RFC 5357 for Session-Sender a= nd Session-Reflector respectively? Probe messages follow the same procedure as defined in RFC 4656 and RF= C 5357. GIM>> All messages, i.e., TWAMP-Test packets as well as the defined in draf= t-gandhi-ippm-twamp-srpm? Yes, unless otherwise specified in the draft-gandhi-ippm-twamp-srpm. * for both delay and loss measurements draft requires test packet be tr= ansmitted on a congruent path: the probe messages are sent on the congruent path of the data traffic by the sender node It is not clear what "the congruent path" means. The definition of congruen= cy in geometry tells us that an object B is congruent to object A if it has= the same shape and size, but is allowed to flip, slide or turn. How a path= can be congruent to another path? Gyan> Agreed. The use of congruent in the context of pathing is con= fusing as the path being addressed may not be reflected accurately by the t= erm congruent. As replied above. There are many existing RFCs that use term Congruent Path (e.g. RFC 59= 21, 6669) without defining them. I suspect it is because it is well-known t= erm. Having said that, we can add a reference for it if it helps reader. GIM>> I cannot assume what was the context of these RFCs. I've sketched a n= etwork diagram above to illustrate that a "congruent path" may well lead to= out-of-band path. Is that the intention of the authors of the draft to use= this protocol out-of-band? As replied above. * The last paragraph in Section 3 refers to work on iOAM: The In-Situ Operations, Administration, and Maintenance (IOAM) mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM information such as timestamp in-band as part of the data packets, and are outside the scope of this document. Is iOAM in the scope of this specification? What are the relationships betw= een iOAM and draft-gandhi-spring-twamp-srpm? As mentioned in the draft, IOAM is outside the scope. GIM>> Yes, but it appears that references to the two IOAM-related drafts ha= ve some purpose. What is it? How are these drafts related to draft-gandhi-s= pring-twamp-srpm? We can remove them if it is confusing. It is informational text (was = added to address a review comment). * Section 3.1 presents an example of the provisioning model but puts th= e definition of the provisioning model outside the scope. Is there an accom= panying specification that defines the provisioning model that can be used = in multi-vendor deployment? Could that be YANG data model? What is the rela= tionship with draft-ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented? Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yang<= https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> and add any miss= ing items in a separate draft. We can also add a reference in this draft. GIM>> I think that theremust be some discussion on how the new protocol is = configured. If TWAMP YANG data model can be augmented, I'd expect that bein= g defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything abo= ut the configuration of the protocol. The Yang model extensions are not in the scope of this draft * Section 4.1 states that a new message is introduced to perform the Lo= ss Measurement in this protocol Why the capability of TWAMP to measure the = loss in one-way and two-way is not sufficient? Existing TWAMP messages do not support =93direct-mode=94 loss measurem= ent. We can add =93direct-mode=94 in the text to clarify. GIM>> True, direct loss measurement, in fact, is not active measurement and= thus is outside the scope of Two-Way Active Measurement Protocol (TWAMP). = The direct-loss measurement is, by the definition of RFC 7799, passive meas= urement method and fetching counters can be done using numerous methods, e.= g., SNMP, Netconf RFC 7799 does not say using Test-packets to collect counters for dire= ct-mod loss measurement is passive. GIM2>> Per RFC 7799, injecting in-band test packets is the characteristic o= f an active measurement method. Using out-of-band transport, e.g., SNMP que= ries, would be an example of a passive measurement method. Ok, so you answered your own question that the direct-mode packet los= s extension defined is =93active measurement=94 method. * Section 4.1.1 requires that The Destination UDP port cannot be used as Source port, since the message does not have any indication to distinguish between the query and response message. Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain? Gyan> Good question Yes, it is unique in the domain. This is user-defined and is up to the user what UDP port to provision = in a domain. GIM>> So, can user configure a port number from the User Ports range? Or, c= an the same port number be used on the same system for a number of test ses= sions? I find the use of UDP port numbers being underspecified. * Section 4.1.2 of RFC 5357 does not define "the delay measurement mess= age" but refers to the definition of the Session-Sender's test packet in RF= C 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet for= mat to perform both delay and packet loss measurement. Ok, we can update the text in the next revision to indicate exact name= from the RFC 4656. We can also add text to include synthetic packet loss. GIM>> I think that making it explicit would help. Also, that will highlight= what is being introduced by *twamp-srpm drafts is, in fact, a new protocol= to perform synthetic packet loss measurement. No, it does not change anything for synthetic packet loss. * Can you explain how "the DM probe query message contains the payload = format defined in Section 4.2.1 of [RFC5357]" when the referenced section o= f RFC 5357 defines the format of a Session-Reflector's test packet? We can update the text in the next revision to indicate query format n= ame from RFC 5357. GIM>> I cannot find any reference to a query format in RFCs 4656/5357. Coul= d you please quote from any of these documents? It is test-packet, we will use RFC 5357 term. * Can clarify the applicability of RFC 6038 and the symmetrical packet = size? Is it required? Can it be non-symmetrical? Yes. Please see section 4.1.1 and quoted below: =93For symmetrical size query and response messages as defined in [RFC6038]= ,=94 GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the sym= metrical test packets. Since *-twamp-srpm proposals do not use TWAMP-Contro= l protocol and Appendix I in RFC 5357 tells us nothing about that either (i= n part because RFC 6038 came later), I don't see that there's any certainty= in what is the sze of a test packet used in the direct-loss measurement. The test-packets as defined in these existing RFCs are used for dela= y and synthetic packet loss. The direct-mode test-packets are defined in th= is draft. GIM2>> This draft defines only a new packet format for the direct packet lo= ss measurement. For STAMP such a mechanism is clearly superfluous given the= Direct Measurement TLV is already defined. As replied earlier. * Can you clarify the use of the timestamp format, NTP or PTPv2? It is = not clear which is the default, mandatory or optional. This is same as TWAMP. There is no change. GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for *-twam= p-srpm? No change in existing in what is there in RFC 5357 and RFC 8186. * Also, is "hardware support in Segment Routing networks" of the PTPv2 = format required, guaranteed, or something else? Hardware timestamps are recommended for SR use-cases. We can change th= e sentence. GIM>> Perhaps you can propose some text, that would be helpful. Ack. * Section 4.1.1.1 stated that A separate user-configured destination UDP port is used for the delay measurement in authentication mode due to the different probe message format. Can that be interpreted that there could be concurrent authenticated and un= authenticated test sessions using this protocol? Would different authentica= tion methods require using unique destination UDP port numbers? Yes, and Yes, and these are based on provisioning. GIM>> But that requirement is far outside the TWAMP, as defined in RFC 5357= . Some Session-Sender can use authenticated and some not. It is part o= f RFC 5357. * Section 4.1.2 by introducing the dedicated Loss measurement packet fo= rmat, effectively modifies the behavior defined in RFC 5357 for Session-Sen= der and Session-Reflector. But the document does not state that. Can you cl= arify whether this specification changes the behavior of a Session-Sender a= nd Session-Reflector as defined in RFC 4656 and RFC 5357 respectively for t= he support of packet loss measurement? The direct-mode loss defines new procedure for sender/reflector to col= lect traffic counters, as opposed to timestamp. The rest is the same as RFC= 4656 and 5357. GIM>> I cannot agree with your statement " The rest is the same as RFC 4656= and 5357" because the sender's direct-loss format does not have Error Esti= mate field, Thus, a reflected packet does not have Sender's Error Estimate,= nor Error Estimate of the reflector. And that, in my opinion, is another c= lear indication that *twamp-srpm drafts define a new protocol, separate fro= m OWAMP/TWAMP. That field is specific to timestamps and would not apply to counters= for direct-mode loss measurement. * And a similar question about the use of the separate UDP port number = for the authenticated of the packet loss measurement. * A couple of question to the following text in Section 4.1.3: The local and remote IP addresses of the link are used as Source and Destination Addresses. They can also be IPv6 link local address as probe messages are pre- routed. * What are the addresses of a link? I am assuming this well-known (e.g. RFC 2328). GIM>> I am not familiar with the term "pre-routed". What does it mean? Ensure that packets are routed over the link. * In which scenarios an IPv6 LLA can be used? I am assuming this is well-known (e.g. RFC 5613). GIM>> So, LLA may be used as the source and destination addresses when test= ing an SR tunnel? As mentioned this is for links. * Also, could the use of a routable destination IP address be used a= s a DDOS attack vector? Consider the scenario when an attacker generates SR= -encapsulated packets with the destination IP address other than any of the= SR-terminating nodes. Such a packet will be routed, correct? That does app= ear as a security threat, would you agree? Absolutely do not agree. It is no different than IP routed TWAMP packe= t as defined in [RFC5357]. GIM>> You don't agree that the processing described cannot happen because o= f laws of physics or it wouldn't happen because no one will think of that? = If the latter, I think that that is security threat. There is no new threat like you have mentioned. GIM2>> Hmmm, but how the integrity of TLVs proposed in draft-gandhi-ippm-st= amp-srpm can be protected? These are not protected by HMAC as presented in = figures 3 and 5. The extensions do not change the processing of these existing TLVs de= fined for HMAC. We can add text to indicate this. * Section 4.1.4.2 references Figure 5 that, as I understand it, display= s the format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflecto= r's reflected packet. Which of the two is used for the delay measurement in= the proposed protocol? The probe query packet in the Session-Sender text packet. We can updat= e the name. * Section 4.2.1 states that In one-way measurement mode, the probe response message as defined in Figure 6 is sent back out-of-band to the sender node ... Could you clarify how the responder controls that the response packet is se= nt not in-band but out-of-band? Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This is = existing behaviour for out-of-band. GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines another= new protocol OWAMP Light. And it is not clear what you reference as "this = is existing behavior". Is it to reference behavior of TWAMP test packet? Bu= t the behavior of the TWAMP-Test protocol by itself is neither in-band, nor= out-of-band. It is the encapsulation of the TWAMP test packet that makes i= t either in-band or out-of-band. Right. * How's the method described in Section 4.2.3 is different from the met= hod described in RFC 8403? What is dis= tinctly unique about the loopback mode proposed in the section? There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403. GIM>> So, you believe that proposing to use the method described in RFC 840= 3 for the TWAMP packet is innovation? And what are the benefits of using th= e TWAMP test packet format in the Loopback mode? Please see the draft. * What is the rationale for setting TTL/Hop Limit fields always to 255 = for IPv4, MPLS, and IPv6 (per Section 4.3.1)? This is as defined in Section 4.2 of RFC 5357 (Bullet 4). GIM>> I believe you've misunderstood the text in RFC 5357. This bullet spec= ifies the behavior of a Session-Reflector. It is to try to read TTL value o= f the received TWAMP test packet and copy the value in Sender TTL field of = the reflected packet. If the Session-Reflector cannot access the TTL field,= it MUST write 255 in the Sender TTL field. So, I think that my questions s= till remains. Please see Section 4.2.1 of RFC 5357. * Section 4.3.3 states that a zero-value UDP checksum may be used in so= me scenarios. RFC 8085 allows that but in very specific cases that are docu= mented in detail in Section 3.4.1. Do you believe that the case of this pro= tocol checks all the requirements for allowing the use of Zero UDP checksum= as specified in RFC 8085? Also, I believe that allowing the use of Zero UD= P checksum in some scenarios, this protocol introduces a security threat th= at must be thoroughly analyzed in the Security Considerations section. This is described in RFC 6936. It will be very specific to the UDP por= t provisioned for TWAMP. We will add reference to RFC 6936 in Security Sect= ion. GIM>> I don't think that the reference is sufficient for the Securit Consid= eration. I'd expect some extended discussion on why using zero UDP header c= hecksum is not a security threat for *twamp-srpm protocol. Please see reply above. * Section 8 refers to "liveness monitoring of Links and SR Paths". This= appears as the replication of functionality provided by BFD/S-BFD protocol= s. Is such comparison accurate? If it is, shouldn't the proposal be also re= viewed by the BFD WG? TWAMP probe messages are used today for synthetic packet loss which c= an also be used to detect connection loss (performance metric). The section= simply highlights this obvious metric. GIM>> Can you point to a document that has defined "TWAMP probe messages a= re used today for synthetic packet loss"? Also, which document defines loss= of connectivity as a performance metric? Does *twamp-srpm proposes to use = the new protocol to detect the loss of path continuity? For example Y.1731 has such notion of connection loss. TWAMP is used= widely for synthetic packet loss and is well-known. There is no change in = protocol. This is reported metric. GIM2>> What are packet transmission frequencies authors envisioned for that= mode? A single-digit millisecond? It depends on the implementation. * I found the Security Section of the proposed protocol inadequately te= rse and missing very important threats that this protocol introduces in the= network. Other than referring RFC 6936 for zero checksum what else is missing? = Otherwise it is no different than RFC 8762 (STAMP). GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The use = of source IP addresses, as mentioned above, appears to be another security = risk introduced by *-twamp-srpm drafts. There is no mention of Source IP address above. * draft-gandhi-ippm-twamp-srpm As I understand it, the motivation for the Loss Measurement mode defined in= this specification is to collect "in-profile" counters. Is that correct? D= o you see as essential for this mode that the query messages are in-band wi= th the flow being profiled? In your opinion, how using an out-of-band metho= d of collecting these counters, e.g., by using ICMP multi-part message exte= nsion per RFC 4884, could affect the accuracy comparing with the method in = this protocol? How the impact changes if extended ICMP messages are in-band= with the profiled flow? Yes, they need to be in-band with the flow, to collect the counter f= rom the right forwarding paths for the flow. Discussion of using ICMP for d= irect-mode loss measurement is outside the scope of this draft. GIM2>> I think that the assumption "they need to be in-band with the flow, = to collect the counter from the right forwarding paths for the flow" is tec= hnically inaccurate. Otherwise, how SNMP queries could work for decades of = networking history? -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD --_000_DM6PR11MB3115AA86AEB65611AFE973A4BFF00DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Hi Gyan,

     

    Thanks for your review= comments. Please see inline with <RG4>=85

     

    From: Gyan Mishra <hay= abusagsm@gmail.com>
    Date: Saturday, December 5, 2020 at 1:16 AM
    To: Greg Mirsky <gregimirsky@gmail.com>
    Cc: Greg Mirsky <gregory.mirsky@ztetx.com>, IETF IPPM WG <i= ppm@ietf.org>, James Guichard <james.n.guichard@futurewei.com>, Ra= kesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.org <i= ppm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org&= gt;, spring@ietf.org <spring@ietf.org>
    Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf= .org/html/draft-gandhi-spring-twamp-srpm-11

    Hi Rakesh 

     

    Had a general question.

     

    I read through the draft again and a question came t= o mind as this draft is Standards Track, what new is being introduced other= then a procedure of how to use TWAMP in SR networks SR-MPLS which reuses t= he MPLS data plane and SRv6 which used the IPv6 data plane.  I don=92t believe there exists  a Sta= ndards track draft procedure for how to use STAMP over IP network or MPLS n= etwork as an example.  

     

    Section 4.1.4 describes SR-MPLS use case and SRv6 us= e case.  As there appears to be nothing new introduced such as a new I= ANA TLV or code point or even a special SID code point  for TWAMP, all= basic vanilla SR, that without this draft you could run STAMP, TWAMP, OWAMP over SR which has existed for a while now. &= nbsp;

     

    What is the new invention here?

     

    <RG4> SPRING dra= fts define the procedure for using TWAMP Light and STAMP test-messages for = SR path and links. The corresponding IPPM drafts define the extensions need= ed for them. The SPRING drafts also use the extensions for them defined in the corresponding IPPM drafts. The extensio= ns are needed for (1) in-band response request e.g. for two-way mode for li= nks and SR path, (2) Return path for SR e.g. when using bidirectional SR Pa= th, and (3) for collecting TX and RX traffic counters in-band for direct-mode loss measurement.

     

    Sorry but I may have missed something.

     

    My thoughts are at most this be a BCP or I am thinki= ng informational draft would be appropriate.

     

    <RG4> Given abov= e context, if WG thinks that any of the drafts should be BCP or Information= al or Experimental, we can update the draft accordingly.<= /p>

     

    Thoughts?

     

    Gyan

     

    Hi Rakesh,

    thank you for the continued discussion. You can find= my follow-up notes in-line below under GIM3>> tag. I felt that one c= omment is at the root of our different views on what is considered to be a = problem that drafts solve. You've said:

    <RG3> As mentioned, the extensions defined are= for the direct-mode packet loss measurement for TWAMP Light and STAMP.

    But draft-ietf-ippm-stamp-option-tlv, currently in  Submitted to IESG = for Publication WG state according to IETF datatracker, includes Section 4.= 5 Direct Measurement TLV. It is noted in the section:

       The Direct Measurement TLV enables coll= ection of the number of in-
       profile packets, i.e., packets that form a specific data flow,= that
       had been transmitted and received by the Session-Sender and Se= ssion-
       Reflector, respectively.  The definition of "in-prof= ile packet" is
       outside the scope of this document and is left to the test ope= rators
       to determine.

     

    <RG4>=

    Hi Greg,

    The motivation has bee= n there in the draft-gandhi-ippm-stamp-srpm, Section 1. Copied below for th= e convenience.

     

       The STAMP message with a TLV fo= r "direct measurement" can be used for

       combined Delay + Loss measureme= nt [I-D.ietf-ippm-stamp-option-tlv].

       However, in order to use only f= or loss measurement purpose, it

       requires the node to support th= e delay measurement messages and

       support timestamp for these mes= sages (which may also require clock

       synchronization).  Further= more, for hardware-based counter collection

       for direct-mode loss measuremen= t, the optional TLV based processing

       adds unnecessary overhead (as c= ounters are not at well-known

       locations).

     

    Thus I cannot see any technical need for the introdu= ction of yet another way of direct loss measurement in STAMP. As for t= he case of TWAMP Light, I believe that there's no sufficient evidence that = the proposed direct loss-measurement measurement method benefits existing implementations of TWAMP Light. Also, historicall= y, all extensions applicable to TWAMP Light have been introduced through ex= tending TWAMP proper, i.e., extending TWAMP-Control and TWAMP-Test. The way= of "extending" TWAMP Light presented in the drafts we are discussing is, in my opinion, in violation of RFC 535= 7.

     

    <RG4> The IPPM W= G Informational draft on TWAMP Light direct-mode loss measurement, defines = the message format and corresponding SPRING draft defines the procedure for= using that. It is not clear to me how providing an informational draft gandhi-ippm-twamp-srpm is violating RFC 5357.<= /o:p>

     

    Thanks,

    Rakesh

     

     

    More notes can be found below.

     

    Regards,

    Greg

     

     

    On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

    Thank you Greg for your further repl= y and the discussions.

    Good to know that you do see a ne= ed for the extensions for the direct-mode packet loss detection and the aut= hors are actively working on an alternate methods using BFD (as you mentioned below).

    GIM3>> As you've recognized, in draft-mirmin-bfd-extended we build an integrated OAM based on the = lightweight Fault Management protocol with optional Performance Monitoring,= based on RFC 6374. RFC 6374, in turn, provides a rich set of performance m= easurement methods, including direct loss measurement.

    Please see replies inline with <R= G3>=85.

    From: Greg Mirsky <gregimirsky@gmail.c= om>
    Date: Monday, November 30, 2020 at 11:30 AM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Gyan Mishra <hayabusagsm@gmail.com>, IETF IPPM WG <ippm@ietf.org>, James Guichard &= lt;jame= s.n.guichard@futurewei.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;, Greg Mirsky <gregory.mirsky@ztetx.com>
    Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

    Hi Rakesh,

    thank you for the continued discussion. I appreciate your response= s. I am still not convinced of the value these documents add. Please find m= y follow-up notes in-line below under the GIM2>> tag.

     Regards,

    Greg 

    On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> = wrote:

    Thank you Gyan and Greg for your rev= iew comments and discussions. Please see inline replies with <RG2>=85=

    From: Gyan Mishra <hayabusagsm@gmail.c= om>
    Date: Wednesday, November 25, 2020 at 12:34 PM
    To: Greg Mirsky <gregimirsky@gmail.com>
    Cc: IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com&g= t;, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;
    Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

     Hi Rakesh 

    I have been following this thread and to help progress the discuss= ion I would like to provide some comments in-line Gyan> =

    Thanks

    Gyan

    On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <gregimirsky@gmail.com> wrot= e:

    Hi Rakesh,

    thank you for the response to my comments. Please find my fol= low-up notes in-lined below under the GIM>> tag. 

    Regards,

    Greg

    On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> = wrote:

    Thank you Greg for taking time for thoroughly= reviewing the documents and providing the comments.

    Please see replies inline with <RG>=85<= /span>

    From: ippm <ippm-bounces@ietf.org&= gt;
    Date: Friday, November 6, 2020 at 11:18 AM
    To: James Guichard <james.n.guichard@futurewei.com>
    Cc: spring@ietf= .org <spring@ie= tf.org>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
    Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

    Dear Chairs of the SPRING and IPPM WGs, Authors, et al.,

    I've found myself in the situation when two related drafts are in = the WG APs in the SPRING and IPPM WG (with the possibility that expertise f= rom the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are c= losely related, I've decided to combine my questions and comments in a sing= le thread. I hope that would be acceptable and considered by the SPRING WG = as well as IPPM WG.

    Usually, the bar for the adoption of a document can be evaluated&n= bsp;by answers to these three questions:

    • Is the document(s) reasonably well-written

    I've got surprised that the drafts don't use the terminology from = RFC 4656 and 5357 and introduce their own terminology for Session-Sender an= d Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents withou= t proper definitions. Other than that both drafts are readable and reasonab= ly well-written.

    <RG> We are ok to change Sender to Se= ssion-Sender and Reflector to Session-Reflector if it helps.

     

    GIM>> I believe that the consistency in terminology between the core = RFC and what is intended as its extension is not only helpful to a reader b= ut, to the best of my understanding, is required for IETF specifications. B= ut I don't think that switching the terminology will fix the fundamental issue with the proposal. The operation that is re= quired from the remote entity, whether it is referred to as responder or Se= ssion-Reflector, is not defined in Appendix I of RFC 5357, nor in RFCs 4656= or 5357 itself. In my opinion, the behavior required, as described in the draft, cannot be characterized = as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely n= ew protocol that, if there's a need in the new PM OAM protocol, must be pro= perly defined.

       Gyan> I am in complete agreement with Greg about t= erminology and consistency.  The problem with inconsistency is that th= at you are not following well known normative references required to understand the specification leading to confusion and misunder= standing of the specification.  The goal should be clear and concise i= n terminology and verbiage.

    <RG2> Agree. Will address the = terms from RFC 5357 in the next revision.

    <RG> There are many existing RFCs tha= t use term =93Link=94 (e.g. RFC 5613, 5340, 8330, etc.) and term =93Congrue= nt Path=94 (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we c= an add a reference for them if it helps.

    GIM>> Thank you for listing these RFCs. I think I need to cl= arify my questions. While a reference to any of RFCs you've mentioned, I do= n't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

    Now I'll try to illustrate my concern with using the term "co= ngruent path" in these drafts (using ASCII-art):

                      &nb= sp;    C---------D

                      &nb= sp;  /                 \<= o:p>

                A----B    &nbs= p;              E-----F

                      &nb= sp;  \                  /=

                      &nb= sp;  G------------H

    Consider an SR tunnel from A to F that traverses the network as A-= B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of "con= gruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and siz= e as the mirror image of the other", it looks as the path A-B-G-H-E-F = is congruent to that SR tunnel. But a packet of an active OAM intended to m= onitor a flow over the SR tunnel is out-of-band relative to that flow and will not produce any meaningful measurement. Of = course, for the case of the extensions in drafts *-twamp-srpm, direct loss = measurement can be performed, as information collected from node F and pack= ets that collect the counters are not required to be in-band with the monitored flow. So, this example, in m= y opinion, illustrates two of my concerns:

    =B7 &n= bsp;       using a congruent path for active performance measurement, e.g., TWA= MP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should= reflect the fundamental requirement of ensuring that active OAM test packets are in-band with the monitored fl= ow.

    =B7 &n= bsp;       there are no technical requirements to justify using in-band test pa= ckets for direct packet loss measurement. In fact, using the in-band method= for collecting in-profile counters leads to a waste of bandwidth, which ma= y have a negative impact on services that require low-latency and/or low packet loss. As demonstrated in this e= xample, direct packet loss can be performed using an out-of-band mechanism,= e.g., SNMP queries, Netconf notifications based on YANG data model.

    • Does the document solve a real problem?

    No, it appears that these drafts define a new performance measurem= ent protocol for the purpose of combining OWAMP and TWAMP functionality and= adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technical ar= guments for using a PM protocol instead of, for example, extending the exis= ting OAM mechanisms like ICMP.

     Gyan>  This may sound basic but is a very critical s= ubject going down the same lines of clarity in verbiage so their is no misu= nderstanding.  =93Congruent=94 by definition means shape of an object and if you super imposed two objects on top of each other the= y fit perfectly and the edges coincide identically.  The problem with = congruent is that it is based on the shape and that shape could be a mirror= image or reflection which may not be exact.  So when referring to a SR-TE path taken this could lead to co= nfusion as to path taken if it=92s the same path or congruent which is vagu= e as to =93exactly=94 which path is taken where here there is criticality a= s to the path being referenced in terms of in-band versus out-of-band.  I agree th= at for direct in band packet loss measurement can be done via existing OAM = mechanisme via ICMP.

    <RG2> Ok, we will find an appr= opriate term for =93sending packets on the same path as data traffic=94.

    <RG2> Extending ICMP for direc= t-mode loss measurement is outside the scope of this draft. But good to see= the agreement for the direct in band packet loss measurement to be done (albeit by some other means).

    GIM2>> I feel that you misunderstand my position in regard t= o the use case these four documents try to solve. I don't recall that I've = stated that "direct in-band packet loss measurement" requires any additional standardization work. The Direct Measurement TLV h= as solved that for STAMP and draft-ietf-ippm-stamp-option-tlv is now in the= RFC Editor's queue. I cannot find any valid technical reason to re-open th= is and measure the direct packet loss in a slightly different way. I must point out that a claim that using= fixed positions for the direct packet loss optimizes performance does not = stand for cases (Section 4.2.1 and 4.2.2 of draft-gandhi-spring-stamp-srpm)= when the return path is specified in the Return Path TLV and, as I understand it, in some cases even the sec= ond TLV, Node Address TLV, is used. Thus, it is clear that the proposed new= method of direct packet loss measurement does not offer any significant be= nefits comparing to the STAMP's Direct Measurement TLV and appears nothing but superfluous.

    <RG3> The direct-mode packet l= oss use-case is typically for the forward direction packet loss. And this d= oes not use the return path TLV. We can clarify that in the draft.

    GIM3>> Clarification would be very helpful as = your latest note might be interpreted that the proposed mechanisms are not = applicable in the case of a bi-directional SR tunnel.

    <RG> There is a requirement to measur= e performance delay as well as synthetic and direct-mode packet loss in seg= ment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measur= ement today. I am not sure extending ICMP for LM is a good option here.

    GIM>> I agree with the requirements you've listed (though the&nb= sp;SPRING WG OAM requirements document has = been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason to use OWAMP/TWAMP for exclusi= ve direct packet loss measurement.  

        Gyan> Agreed

    <RG2> There is definitely a need to = do direct-mode loss measurement in IP/SR networks, as RFC 6374 mechanisms a= re for MPLS networks. Note that there was an attempt to extend BFD for dire= ct-mode loss measurement for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03)= .

    GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense. The work and discussion of= the proposal continues and the new version will be published soon.

    <RG3> Ok, so you do see a n= eed for the extensions for the direct-mode packet loss detection and the au= thors are actively working on an alternate methods using BFD.   

    • Is the proposed solution technically viable?

    There are too many unaddressed aspects, particularly the risk intr= oduced by the protocol on network security, to comprehensively evaluate the= proposed solution.

    <RG> About your comment on zer= o checksum, this is described in Security section in RFC 6936. We will add = reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

    GIM>> I don't think that a mere reference sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol.

         Gyan> Agreed 0 UDP MIMA security threats an= d that you need to thorough vetting of RFC 6936.

     <RG2> Yes, will add in t= he next revision. Hope we can work together on needed text.

    To summarize my review of these two drafts:

    • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

    <RG> The probe and response me= ssages defined in [RFC 5357] are used for delay measurement and synthetic p= acket loss. The direct-mode packet loss messages are defined in draf= t-gandhi-ippm-twamp-srpm that matc= h these delay measurement messages. As stated, draft-gandhi-ippm-tw= amp-srpm defines =93extensions=94 = for TWAMP Light.

    GIM>> I cannot find where RFC 5357 defines "the probe and respon= se messages". Could you give a more specific reference or provide the = text that, in your opinion, defines such messages? But I'm more concerned w= ith the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to BBF's TR-390, I'm = have learned how different are existing implementations of TWAMP Light. And= that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

      Gyan> I don=92t see the probe a d response messages in T= WAMP RFC 5357 

    <RG2> Agree to use term test-p= acket from RFC 5357.

    =B7 &n= bsp;       several parts of the proposed protocol, e.g., Zero UDP checksum in I= Pv6, require detailed security analysis, which is currently absent;

         Gyan> Agreed 

    <RG2> Please see previous repl= y.

    <RG> This is specified in RFC = 6936 Security Section. We will add reference to this RFC in our Security Se= ction as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

    GIM>>  I've noted above that a simple reference does not suffici= ently explains why the use of zero UDP checksum in IPv6 header is not decre= mental, does not create a security risk for the protocol. I believe that th= e proposal to use zero UDP header checksum requires extensive analysis, using the analysis provided in RFC 6936.=

        Gyan> Completely Agree

     <RG2> Please see previou= s reply.

    • I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
    <RG> This was to address your previous comment qu=
oted as:
     =93- as I understand, the draft is=
 applicable to TWAMP Light mode,

       mentioned in the informational Appendix I in = RFC 5357, not the TWAMP

       protocol itself. Since TWAMP Light is not a s= tandard but its idea is

       described in the informational text only, I t= hink that the Informational

      track is more appropriate for this specification.= =94

    https://m= ailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/

    <RG> Having said that, we are = ok to change to PS.

    GIM>> As explained in RFC 8545 "TWAMP Light is an idea", no= t a protocol. If anyone is interested in standardizing an "extension&q= uot;, I'd expect that they first define the base specification to which the= extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Could you= point to the definition, for example, of the Authenticated mode in TWAMP L= ight in the draft-gandhi-spring-twamp-srpm or RFC 5357? 

         Gyan> Agreed 

    <RG2> The Appendix I of RFC 53= 57 does have information on the Authentication mode. As specified there, th= is is based on user configured parameters.

    =B7 &n= bsp;       I believe that draft-gandhi-spring-twamp-srpm should be anchore= d at IPPM WG as it does introduce the new PM protocol.

    <RG> The TWAMP Light extension draft-gandhi-ippm-tw= amp-srpm is already in IPPM WG. The SPRING draft only = defines SR PM procedures.

     Below, please find my detailed comments, questions on t= hese drafts:

    • draft-gandhi-spring-twamp-srpm

    I have several questions about the relationships between this draf= t and Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light = has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained i= n Section 4 of RFC 8545 (apologies for the long quote):

       "TWAMP Light" is an idea described in Appen= dix I ("TWAMP Light
       (Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
       control protocol combined with the TWAMP-Test protocol.  = In
       [RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
       TWAMP Light failed to meet the requirements for IETF protocols= (there
       are no specifications for negotiating this form of operation a= nd no
       specifications for mandatory-to-implement security features), = as
       described in Appendix A of this memo.  See also [LarsAD] = and
       [TimDISCUSS].

       Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br>    component of TWAMP, it is considered reasonable for future sys= tems to
       use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
       is specified in this document).  Clearly, the TWAMP Light= idea
       envisions many components and communication capabilities beyon= d
       TWAMP-Test (implementing the security requirements, for exampl= e);
       otherwise, Appendix I of [RFC5357] would be one sentence long<= br>    (equating TWAMP Light with TWAMP-Test only).

     Since we don't have an IETF document that addressed these op= en questions, I don't think we can have a draft that proposes extensions to= a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.

     Gyan> Agreed 

    <RG2> The procedure for using = the RFC 5357 defined messages in TWAMP Light configuration mode is defined = in the corresponding spring drafts. It also describes the provisioning model.

    GIM2>> If a return path can be provisioned for TWAMP Light, = why the same method of controlling a test session cannot be used for STAMP?=

    <RG3> It is not expected that = all STAMP TLV extensions need to be supported for TWAMP Light using provisi= oning. 

     <RG> This was to address= your previous comment quoted as

     =93- as I understand, the draft is=
 applicable to TWAMP Light mode,

       mentioned in the informational Appendix I in = RFC 5357, not the TWAMP

       protocol itself. Since TWAMP Light is not a s= tandard but its idea is

       described in the informational text only, I t= hink that the Informational

       track is more appropriate for this specificat= ion.=94

    https://m= ailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/

    <RG> Having said that, we are = ok to change to PS as you mentioned above.

    <RG> BTW, despite only differe= nce of fixed vs. variable length payload in STAMP vs. TWAMP Light, the STAM= P is a proposed standard as RFC 8762 (and it uses the same approach of provisioning  as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

    GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, = and thus the light, simpler, version of TWAMP-Test component of TWAMP proto= col. I cannot find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of TWAMP Light. Also, I'll prefer not= to refer to RFC 8762 STAMP in the discussion of "extension" to T= WAMP Light.

    <RG2> The Authentication infor= mation is user-configured as shown in Section 3.1 of the draft-gandhi-sprin= g-twamp-srpm, and is also described in Appendix I of RFC 5357.

    Now a number of more specific questions.

    draft-gandhi-spring-twamp-srpm:

    • In the Introduction it is stated that:

      The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provid= es
       simplified mechanisms for active performance measurement in Cu= stomer
       IP networks by provisioning UDP paths and eliminates the need = for
       control-channel signaling.

    I can not find where, either Appendix I or TR-390, "elim= inated the need for control-channel signaling". Also, could you point = where the referenced documents describe "provisioning UDP paths"?

    <RG> The Appendix I of RFC 5357 has following tex=
t. We can reword and match the exact text if you prefer.<=
/pre>

     
    

    =93This example eliminates the need=
 for the TWAMP-Control protocol, and
    

       assumes that the Session-Re=
flector is configured=94

    GIM>> I think that the text you're proposing is even more co= nfusing. It is not clear which example the sentence is referring to. Also, = what is the basis for such an assumption? 

    <RG2> This is the exact text f= rom RFC 5357 Appendix I. Please go through the entire Section in that RFC 5= 357 to avoid =93out of context=94 discussion.

    • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

       The procedure uses the mechanisms defined in [RFC5357= ]
       (TWAMP Light) and its extensions for Performance Measurement.<= o:p>

    I think that the reference must be to Appendix I, not RFC 5357. Al= so, could you please specify which extensions of TWAMP Light have been used= in this draft?

    <RG> We can add the Appendix I as ref= erence in the next revision. Extensions are defined in draft-gandhi-ippm-tw= amp-srpm, we can add this reference.

    GIM>> The problem, in my view, is that Appendix I of RFC 535= 7 must be a normative reference while it is, by its nature, an Informationa= l document.  

    <RG2> If approved, it is fine = to have informational draft/RFC in a normative reference. But RFC 5357 is P= S.

    • In Section 2.3 describing the reference model is noted:

      •    The probe response message is typically sent to the s= ender node R1.

      In which scenarios the reflector acts differently? How such behavi= or is related to the behavior of a TWAMP Session-Reflector, as defined in R= FC 5357?

      <RG> Do you prefer we remove =93typic= ally=94 from the sentence?

    GIM>> If that fits into the operational model of the new pro= tocol you're defining. 

    • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

    <RG> Both, please see Section = 4.1.3. =93Link=94 is well known term used in many existing RFCs (please see= RFC 5613, 5340, 8330).

    GIM>> Thank you for the references. I couldn't find a defini= tion of an object "Link" (capitalized) but only "link" = (lower case). Hence, since the draft consistently uses the capitalized form, I consider it to be something else, something different from a link.=  

    <RG2> Ok, we can change Link t= o link in the next revision to avoid confusion.

    • In Section 3 behavior of the reflector described as

       ... no PM state for delay or loss measurement need to= be created on the
       reflector node R5.

    That is in contradiction to the behavior of a TWAMP Session-Reflec= tor as defined in RFC 5357. Could you provide a reference to an IETF standa= rd where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way= delay and synthetic loss measurement on a bidirectional SR tunnel?

     Gyan> Valid point 

    <RG2> Bidirectional SR tunnel = may have an SR state but the statement above is that no PM (i.e. TWAMP Ligh= t) protocol session state is created for it. We can clarify in the next revision.

    GIM2>> So-called stateless Session-Reflector in TWAMP Light = is only one option. I am well-familiar with the implementation that uses th= e stateful mode. 

    <RG3> What information statefu= l PM need to maintain in the state on the reflector? Doesn=92t that cause s= cale issues. We can add in the draft you if there is anything specifically needed in the spec.

    GIM3>> RFCs 5357 and 8762 are clear about what= information must be maintained by a Session-Reflector. The Session-Reflect= or must have knowledge of the test session state and count reflected test p= ackets. The value of such a counter must be copied in the Sequence Number field of the reflected packet. Thus = the method enables the measurement of the one-way packet loss metric.<= /o:p>

     <RG> Quoting the text fr= om Appendix I in RFC 5357. We can quote the text as is. 

    =93In the case of TWAMP Light, the Sessi=
on-Reflector does not necessarily have knowledge of the session state. =93<=
/span>

    GIM>> By the informational nature of Appendix I, the text is= not normative. I am familiar with the implementation of TWAMP Light which = does maintain the session state and thus supports one-way packet loss measurement. If you require that the remote node does = not maintain the state, the draft must define that as part of the specifyin= g the behavior of the protocol.

     <RG2> Ok, we can discuss= what information is to be maintained in that state on the reflector for sy= nthetic packet loss. We can add appropriate text if you can help please.

    GIM2>> I don't see any reason to do that as that already def= ined in RFC 8762 and draft-ietf-ippm-stamp-yang 

    <RG3> Ok. 

    =B7 &n= bsp;       Further, in Section 3 the selection of UDP port explained as the fol= lowing:

       As specified in [RFC8545], the reflector
       supports the destination UDP port 862 for delay measurement pr= obe
       messages by default.  This UDP port however, is not used = for loss
       measurement probe messages.

    To the best of my understanding, as one of the contributors and&nb= sp;Editors of RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Ses= sion-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in th= e same test session, using the same flow of TWAMP-Test packets.<= /p>

     Gyan> Agreed 

    <RG2> Yes, we can use port 862= for both delay and synthetic packet loss =96 they are using the same test = packet. There is no change proposed in the draft.

    GIM2>> Packet delay and synthetic packet loss measurements a= re already supported in RFC 8762. Are you proposing a new protocol to dupli= cate the STAMP functionalities?

    <RG3> As mentioned, the extens= ions defined are for the direct-mode packet loss measurement for TWAMP Ligh= t and STAMP.

    <RG> The packet loss in existi= ng RFC 5357 refers to synthetic loss as there is no support for direct-mode= loss in RFC 5357. We can change the text to clarify as =93This UDP port however, is not used for direct-mode loss meas= urement probe messages.=94

    GIM>> I've found that there's some misconception in the draf= t. RFC 8545 re-assigned UDP port 862 not for "delay measurement probe = messages" but for TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, packet loss, reordering (RFC 473= 7 defines packet reordering metric), and packet duplication measurement.

    • Then the draft states that

    The sender uses the UDP port number following the guidelines speci= fied in Section 6 in [RFC6335].

    Could you point to the guidelines that a user can use when selecti= ng a UDP port number of a test session?

    Gyan> Good point  

    <RG> Please see section 6 in [RFC6335= ]. We can cite the range which will be the same as used in [RFC8762]. This = was also discussed earlier.

    https://mailarchive.ietf.org/arch/msg/i= ppm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

    GIM>> I've looked through Section 6 but I don't find anythin= g specifically applicable to this draft we're discussing. If the protocol t= o use UDP port numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it seems that stating that expli= citly would be the best way. 

    <RG2> This would be, User Ports and Dynamic Ports=
 ranges, which are defined in [RFC6335=
]. Yes, we can add this text.
    • At the closing of the paragraph, we read that

      The number of UDP ports with PM functionality needs to be m= inimized due
       to limited hardware resources.

    Does a UDP port number pose PM functionality? How it is assigned t= o the port number?

    <RG> UDP ports are user config= ured for delay and direct-mode loss PM as described in Section 3.1.<= o:p>

    GIM>> Can UDP port 862 be used? Also, requiring that the dir= ect-loss measurement uses port number different from the one used by a TWAM= P-Test packet, in my opinion, is another indication that this is the definition of a different from TWAMP Light PM OAM protoco= l. 

    <RG2> If we add a field in the= packet then UDP port 862 may be used along with the new field. But it will= require extra processing in hardware. It is better to use a different UDP port for processing efficiency in hardware.<= /span>

    • Following the above-quoted text, in Section 3 is noted:

      •    For Performance Measurement, probe query and response= messages are
         sent as following:

      Could you clarify if the listed further procedures deviate from OW= AMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for Session= -Sender and Session-Reflector respectively?

      <RG> Probe messages follow the same p= rocedure as defined in RFC 4656 and RFC 5357.

    GIM>> All messages, i.e., TWAMP-Test packets as well as the = defined in draft-gandhi-ippm-twamp-srpm? 

     <RG2> Yes, unless otherw= ise specified in the draft-gandhi-ippm-twamp-srpm.

    • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

          the probe messages are sent on the
          congruent path of the data traffic by the sender node<= o:p>

    It is not clear what "the congruent path" means. The definition o= f congruency in geometry tells us that an object B is congruent t= o object A if it has the same shape and size, but is allowed to flip, slide= or turn. How a path can be congruent to another path?

           Gyan> Agreed.  The use of congr= uent in the context of pathing is confusing as the path being addressed may= not be reflected accurately by the term congruent.

    <RG2> As replied above.=

    <RG> There are many existing R= FCs that use term Congruent Path (e.g. RFC 5921, 6669) without defining the= m. I suspect it is because it is well-known term. Having said that, we can add a reference for it if it helps reader.<= /span>

    GIM>> I cannot assume what was the context of these RFCs. I'= ve sketched a network diagram above to illustrate that a "congrue= nt path" may well lead to out-of-band path. Is that the intention of the authors of the draft to use this protocol out-of-band= ?

    <RG2> As replied above.=

    • The last paragraph in Section 3 refers to work on iOAM:

      •    The In-Situ Operations, Administration, and Maintenan= ce (IOAM)
         mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
         SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
         information such as timestamp in-band as part of the data pack= ets,
         and are outside the scope of this document.

      Is iOAM in the scope of this specification? What are the relations= hips between iOAM and draft-gandhi-spring-twamp-srpm?

      <RG> As mentioned in the draft, IOAM = is outside the scope.

    GIM>> Yes, but it appears that references to the two IOAM-re= lated drafts have some purpose. What is it? How are these drafts related to=  draft-gandhi-spring-twamp-srpm? 

    <RG2> We can remove them if it= is confusing. It is informational text (was added to address a review comm= ent).

    • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?

    <RG> Yes, this can be Yang mod= el. We can review draft-ietf-ippm-twamp-yan= g and add any missing items in a s= eparate draft. We can also add a reference in this draft.

    GIM>> I think that theremust be some discussion on how = the new protocol is configured. If TWAMP YANG data model can be augmented, = I'd expect that being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything about the configuration of the protocol. = ;

    <RG2> The Yang model extension= s are not in the scope of this draft 

    • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

    <RG> Existing TWAMP messages d= o not support =93direct-mode=94 loss measurement. We can add =93direct-mode= =94 in the text to clarify.

    GIM>> True, direct loss measurement, in fact, is not active = measurement and thus is outside the scope of Two-Way Active Measurement Pro= tocol (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, passive measurement method and fetching= counters can be done using numerous methods, e.g., SNMP, Netconf 

    <RG2> RFC 7799 does not say us= ing Test-packets to collect counters for direct-mod loss measurement is pas= sive.

    GIM2>> Per RFC 7799, injecting in-band test packets is the c= haracteristic of an active measurement method. Using out-of-band transport,= e.g., SNMP queries, would be an example of a passive measurement method. 

    <RG3> Ok, so you answered your= own question that the direct-mode packet loss extension defined is =93acti= ve measurement=94 method.

    • Section 4.1.1 requires that

      The Destination UDP port cannot be used as Source port, sin= ce
       the message does not have any indication to distinguish betwee= n the
       query and response message.

    Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain?

           Gyan> Good question =

    <RG2> Yes, it is unique in the= domain.

    <RG> This is user-defined and = is up to the user what UDP port to provision in a domain.=

    GIM>> So, can user configure a port number from the User Por= ts range? Or, can the same port number be used on the same system for a num= ber of test sessions? I find the use of UDP port numbers being underspecified.

    • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test packet i= n RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet= format to perform both delay and packet loss measurement.

    <RG> Ok, we can update the tex= t in the next revision to indicate exact name from the RFC 4656. We can als= o add text to include synthetic packet loss.

    GIM>> I think that making it explicit would help. Also, that= will highlight what is being introduced by *twamp-srpm drafts is, in fact,= a new protocol to perform synthetic packet loss measurement. 

     <RG2> No, it does not ch= ange anything for synthetic packet loss.

    • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?

    <RG> We can update the text in= the next revision to indicate query format name from RFC 5357.=

    GIM>> I cannot find any reference to a query format in RFCs = 4656/5357. Could you please quote from any of these documents?

     <RG2> It is test-packet,= we will use RFC 5357 term.

    • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
    <RG> Yes. Please see section 4.1.1 and quoted bel=
ow:
    =93For symmetrical size query and respon=
se messages as defined in [RFC6038],=94

    GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL= use of the symmetrical test packets. Since *-twamp-srpm proposals do not u= se TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about that either (in part because RFC 6038 came= later), I don't see that there's any certainty in what is the sze of a tes= t packet used in the direct-loss measurement. 

     <RG2> The test-packets a= s defined in these existing RFCs are used for delay and synthetic packet lo= ss. The direct-mode test-packets are defined in this draft.

    GIM2>> This draft defines only a new packet format for the d= irect packet loss measurement. For STAMP such a mechanism is clearly superf= luous given the Direct Measurement TLV is already defined. 

    <RG3> As replied earlier.

    • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

    <RG> This is same as TWAMP. Th= ere is no change.

    GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the = case for *-twamp-srpm? 

     <RG2> No change in exist= ing in what is there in RFC 5357 and RFC 8186.

    • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

    <RG> Hardware timestamps are r= ecommended for SR use-cases. We can change the sentence.<= /p>

    GIM>> Perhaps you can propose some text, that would be helpf= ul. 

     <RG2> Ack.

    • Section 4.1.1.1 stated that

       A separate user-configured
       destination UDP port is used for the delay measurement in
       authentication mode due to the different probe message format.=

    Can that be interpreted that there could be concurrent authenticat= ed and unauthenticated test sessions using this protocol? Would different a= uthentication methods require using unique destination UDP port numbers?

    <RG> Yes, and Yes, and these a= re based on provisioning.

    GIM>> But that requirement is far outside the TWAMP, as defi= ned in RFC 5357.

     <RG2> Some Session-Sende= r can use authenticated and some not. It is part of RFC 5357.

    • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

    <RG> The direct-mode loss defi= nes new procedure for sender/reflector to collect traffic counters, as oppo= sed to timestamp. The rest is the same as RFC 4656 and 5357.

    GIM>> I cannot agree with your statement " The rest is = the same as RFC 4656 and 5357" because the sender's direct-loss format= does not have Error Estimate field, Thus, a reflected packet does not have Sender's Error Estimate, nor Error Estimate of the re= flector. And that, in my opinion, is another clear indication that *twamp-s= rpm drafts define a new protocol, separate from OWAMP/TWAMP.

     <RG2> That field is spec= ific to timestamps and would not apply to counters for direct-mode loss mea= surement.

    • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
    • A couple of question to the following text in Section 4.1.3:

       The local and remote IP
       addresses of the link are used as Source and Destination Addre= sses.
       They can also be IPv6 link local address as probe messages are= pre-
       routed.

      • What are the addresses of a link?

    <RG> I am assuming this well-k= nown (e.g. RFC 2328).

    GIM>> I am not familiar with the term "pre-routed"= . What does it mean? 

     <RG2> Ensure that packet= s are routed over the link.

      • In which scenarios an IPv6 LLA can be used?

    <RG> I am assuming this is wel= l-known (e.g. RFC 5613).

    GIM>> So, LLA may be used as the source and destination addr= esses when testing an SR tunnel? 

     <RG2> As mentioned this = is for links.

      • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such a packet will be routed, correct? That does appear as a security threat, would you agree= ?

    <RG> Absolutely do not agree. = It is no different than IP routed TWAMP packet as defined in [RFC5357].

    GIM>> You don't agree that the processing described cannot h= appen because of laws of physics or it wouldn't happen because no one will = think of that? If the latter, I think that that is security threat.

     <RG2> There is no new th= reat like you have mentioned.

    GIM2>> Hmmm, but how the integrity of TLVs proposed in = draft-gandhi-ippm-stamp-srpm can be protected? These are not protected= by HMAC as presented in figures 3 and 5.     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   

    <RG3> The extensions do not ch= ange the processing of these existing TLVs defined for HMAC. We can add tex= t to indicate this.

    • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the&= nbsp;format of a probe query message. In figure two references to RFC 5357 = are provided - a section that references RFC 4656 OWAMP definition of the S= ession-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the two is= used for the delay measurement in the proposed protocol?

      • <RG> The probe query packet in= the Session-Sender text packet. We can update the name.<= /p>

      • Section 4.2.1 states that

         In one-way measurement mode, the probe response messa= ge as defined in
         Figure 6 is sent back out-of-band to the sender node ...<= /o:p>

      Could you clarify how the responder controls that the response pac= ket is sent not in-band but out-of-band?

      <RG> Please refer to section 3= .1 in draft-gandhi-ippm-twamp-srpm.  This is existing behaviour for ou= t-of-band.

    GIM>> draft-gandhi-ippm-twamp-srpm does not specify tha= t it defines another new protocol OWAMP Light. And it is not clear what you= reference as "this is existing behavior". Is it to reference behavior of TWAMP test packet? But the behavior of the TWAMP-= Test protocol by itself is neither in-band, nor out-of-band. It is the enca= psulation of the TWAMP test packet that makes it either in-band or out-of-b= and. 

     <RG2> Right.=

    GIM>> So, you believe that proposing to use the method descr= ibed in RFC 8403 for the TWAMP packet is innovation? And what are the benef= its of using the TWAMP test packet format in the Loopback mode?

     <RG2> Please see the dra= ft.

    • What is the rationale for setting TTL/Hop Limit fields always to 255 for IP= v4, MPLS, and IPv6 (per Section 4.3.1)?

    <RG> This is as defined in Sec= tion 4.2 of RFC 5357 (Bullet 4).

    GIM>> I believe you've misunderstood the text in RFC 5357. T= his bullet specifies the behavior of a Session-Reflector. It is to try to r= ead TTL value of the received TWAMP test packet and copy the value in Sender TTL field of the reflected packet. If the Ses= sion-Reflector cannot access the TTL field, it MUST write 255 in the Sender= TTL field. So, I think that my questions still remains.

     <RG2> Please see Section= 4.2.1 of RFC 5357.

    • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be= lieve that allowing the use of Zero UDP checksum in some scenarios, this pr= otocol introduces a security threat that must be thoroughly analyzed in the= Security Considerations section.

    <RG> This is described in RFC = 6936. It will be very specific to the UDP port provisioned for TWAMP. We wi= ll add reference to RFC 6936 in Security Section.

    GIM>> I don't think that the reference is sufficient for the= Securit Consideration. I'd expect some extended discussion on why usi= ng zero UDP header checksum is not a security threat for *twamp-srpm  protocol.

     <RG2> Please see reply a= bove.

    • Section 8 refers to "liveness monitoring of Links and SR Paths". = This appears as the replication of functionality provided by BFD/S-BFD prot= ocols. Is such comparison accurate? If it is, shouldn't the proposal be als= o reviewed by the BFD WG?

    <RG> TWAMP  probe message= s are used today for synthetic packet loss which can also be used to detect= connection loss (performance metric). The section simply highlights this obvious metric.

    GIM>> Can you point to a document that has defined "TWA= MP  probe messages are used today for synthetic packet loss"? Als= o, which document defines loss of connectivity as a performance metric? Does *twamp-srpm proposes to use the new protocol to detect the lo= ss of path continuity?

     <RG2> For example Y.1731= has such notion of connection loss. TWAMP is used widely for synthetic pac= ket loss and is well-known. There is no change in protocol. This is reported metric.

    GIM2>> What are packet transmission frequencies authors envi= sioned for that mode? A single-digit millisecond? 

    <RG3> It depends on the implem= entation.

    • I found the Security Section of the proposed protocol inadequately terse an= d missing very important threats that this protocol introduces in the netwo= rk.

    <RG> Other than referring RFC = 6936 for zero checksum what else is missing? Otherwise it is no different t= han RFC 8762 (STAMP).

    GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm d= rafts. The use of source IP addresses, as mentioned above, appears to be an= other security risk introduced by *-twamp-srpm drafts. 

     <RG2> There is no mentio= n of Source IP address above.

    • draft-gandhi-ippm-twamp-srpm

    As I understand it, the motivation for the Loss Measurement mode d= efined in this specification is to collect "in-profile" counters.= Is that correct? Do you see as essential for this mode that the query messages are in-band with the flow being profiled= ? In your opinion, how using an out-of-band method of collecting these coun= ters, e.g., by using ICMP multi-part message extension per RFC 4884, c= ould affect the accuracy comparing with the method in this protocol? How the impact changes if extended ICMP messa= ges are in-band with the profiled flow?

     <RG2> Yes, they need to = be in-band with the flow, to collect the counter from the right forwarding = paths for the flow. Discussion of using ICMP for direct-mode loss measurement is outside the scope of this draft.

    GIM2>> I think that the assumption "they need to be in-= band with the flow, to collect the counter from the right forwarding paths = for the flow" is technically inaccurate. Otherwise, how SNMP queries could work for decades of networking history?<= /p>

     

    --

    --_000_DM6PR11MB3115AA86AEB65611AFE973A4BFF00DM6PR11MB3115namp_-- From nobody Sat Dec 5 11:23:22 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E223A0AC1; Sat, 5 Dec 2020 11:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gsxzP-VB1aVQ; Sat, 5 Dec 2020 11:23:08 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C4B3A0ABE; Sat, 5 Dec 2020 11:23:08 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id f17so5690138pge.6; Sat, 05 Dec 2020 11:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DfHTkuCXMb1EwH9YP+h9aoyAU1S3jBx0c/vN2vy8LS8=; b=u1ZzoO1/qJ/Rt/nfevXA2g9Hx7bsunMWCWQyftB9J+Mj6zHjkO2GvCOYi8xEQOLNdz bcwjvvSDdYR+5+/dvdHcik9rfMwSeoJjcnMOI8LGfBpFrrEl74HusEnQUgYV1QhzN3oX NXHYqO4VZnpKyhwV4+j/X/aLhlUbRGpyyw3EDPbZLzZeiXL+uNksWbZvFGiDhG4pGxJ7 EkPrkxZb2Wbl57E1b1FWaLfkR1m7mVTKKFkGaHz4FSguHuhQFqS04IxGAd3c2uk+ZFYB 1uVVU4qSHjSmqIut3AQTVF+GhP4/cn46Q7amcCDDbi+XUBrqF1uarjTxM9K/qzDnkrLj +Tug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DfHTkuCXMb1EwH9YP+h9aoyAU1S3jBx0c/vN2vy8LS8=; b=oqgu27gWbWI12LCn/Gfyxbnz/Ev5phl2T9Zz6sj4HZUceCxpwr5uTy9xC0wC8tQl2y N1+wtxWvssUTDRVQV/6wrJCTKeS3lVx8nzoCAvquEysSopayIhN8b6kPG8fskufwCVGj ffWGkfBm8tizBPbewX0P0iPmq7+ww0awwWTPco8OY0KDWd4HZEU4bZD7J2UeZPIaWnwz o8nhFHpB2PiPETqX9HyVXKJhgOzMfCx/bng8s4R26TLvYlzOri076iSjiNobYe8YHZH1 k4cjk3yfkld3wErtpC8u9eB5uxJhLyQ4ZfAHwDAY5aLes6A049O05aqbPfxSnm/jHG7t t37A== X-Gm-Message-State: AOAM5320gWavV4aKtxB+SQLX5pwlg2BBDDR6kkWNCX0HxkoOpbo2Q9fA 6Ff6B+m+KfubJpiDlzJqRYNOqIIf7vyUQ2YEfko= X-Google-Smtp-Source: ABdhPJzSoneayfQfuWpUrfQsvxfRvZarw1wCmQsyGIXrqnbuu6fCBU0cyaY3QT9iuHhfIvBxXQ1qkRsklEFkUz0GVoA= X-Received: by 2002:a65:5ac4:: with SMTP id d4mr3407642pgt.50.1607196187043; Sat, 05 Dec 2020 11:23:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sat, 5 Dec 2020 14:22:55 -0500 Message-ID: To: "Rakesh Gandhi (rgandhi)" Cc: Greg Mirsky , Greg Mirsky , IETF IPPM WG , James Guichard , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d02cca05b5bc855d" Archived-At: Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 19:23:17 -0000 --000000000000d02cca05b5bc855d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rakesh Please see in-line On Sat, Dec 5, 2020 at 10:32 AM Rakesh Gandhi (rgandhi) wrote: > Hi Gyan, > > > > Thanks for your review comments. Please see inline with =E2=80=A6 > > > > *From: *Gyan Mishra > *Date: *Saturday, December 5, 2020 at 1:16 AM > *To: *Greg Mirsky > *Cc: *Greg Mirsky , IETF IPPM WG , > James Guichard , Rakesh Gandhi (rgandhi) = < > rgandhi@cisco.com>, ippm-chairs@ietf.org , > spring-chairs@ietf.org , spring@ietf.org < > spring@ietf.org> > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh > > > > Had a general question. > > > > I read through the draft again and a question came to mind as this draft > is Standards Track, what new is being introduced other then a procedure o= f > how to use TWAMP in SR networks SR-MPLS which reuses the MPLS data plane > and SRv6 which used the IPv6 data plane. I don=E2=80=99t believe there e= xists a > Standards track draft procedure for how to use STAMP over IP network or > MPLS network as an example. > > > > Section 4.1.4 describes SR-MPLS use case and SRv6 use case. As there > appears to be nothing new introduced such as a new IANA TLV or code point > or even a special SID code point for TWAMP, all basic vanilla SR, that > without this draft you could run STAMP, TWAMP, OWAMP over SR which has > existed for a while now. > > > > What is the new invention here? > > > > SPRING drafts define the procedure for using TWAMP Light and STAMP > test-messages for SR path and links. The corresponding IPPM drafts define > the extensions needed for them. The SPRING drafts also use the extensions > for them defined in the corresponding IPPM drafts. The extensions are > needed for (1) in-band response request e.g. for two-way mode for links a= nd > SR path, (2) Return path for SR e.g. when using bidirectional SR Path, an= d > (3) for collecting TX and RX traffic counters in-band for direct-mode los= s > measurement. > > Gyan> Understood. Just to see if a precedence has already been set if > you point me another case where Spring or any other WG RFC Standards Trac= k > that has defined procedures to use IPPM extensions. If this is the firs= t > and may also set a new precedent, I think it=E2=80=99s a valid WG discus= sion. > > Sorry but I may have missed something. > > > > My thoughts are at most this be a BCP or I am thinking informational draf= t > would be appropriate. > > > > Given above context, if WG thinks that any of the drafts should be > BCP or Informational or Experimental, we can update the draft accordingly= . > > Gyan> Agreed. Thank you > > Thoughts? > > > > Gyan > > > > On Thu, Dec 3, 2020 at 12:51 PM Greg Mirsky wrote= : > > Hi Rakesh, > > thank you for the continued discussion. You can find my follow-up notes > in-line below under GIM3>> tag. I felt that one comment is at the root of > our different views on what is considered to be a problem that drafts > solve. You've said: > > As mentioned, the extensions defined are for the direct-mode packet > loss measurement for TWAMP Light and STAMP. > > But draft-ietf-ippm-stamp-option-tlv > , > currently in Submitted to IESG for Publication WG state according to IET= F > datatracker, includes Section 4.5 Direct Measurement TLV. It is noted in > the section: > > The Direct Measurement TLV enables collection of the number of in- > profile packets, i.e., packets that form a specific data flow, that > had been transmitted and received by the Session-Sender and Session- > Reflector, respectively. The definition of "in-profile packet" is > outside the scope of this document and is left to the test operators > to determine. > > > > > > Hi Greg, > > The motivation has been there in the draft-gandhi-ippm-stamp-srpm, Sectio= n > 1. Copied below for the convenience. > > > > The STAMP message with a TLV for "direct measurement" can be used for > > combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv > > ]. > > However, in order to use only for loss measurement purpose, it > > requires the node to support the delay measurement messages and > > support timestamp for these messages (which may also require clock > > synchronization). Furthermore, for hardware-based counter collection > > for direct-mode loss measurement, the optional TLV based processing > > adds unnecessary overhead (as counters are not at well-known > > locations). > > > > Thus I cannot see any technical need for the introduction of yet another > way of direct loss measurement in STAMP. As for the case of TWAMP Light, = I > believe that there's no sufficient evidence that the proposed direct > loss-measurement measurement method benefits existing implementations of > TWAMP Light. Also, historically, all extensions applicable to TWAMP Light > have been introduced through extending TWAMP proper, i.e., extending > TWAMP-Control and TWAMP-Test. The way of "extending" TWAMP Light presente= d > in the drafts we are discussing is, in my opinion, in violation of RFC 53= 57. > > > > The IPPM WG Informational draft on TWAMP Light direct-mode loss > measurement, defines the message format and corresponding SPRING draft > defines the procedure for using that. It is not clear to me how providing > an informational draft gandhi-ippm-twamp-srpm is violating RFC 5357. > > > > Thanks, > > Rakesh > > > > > > More notes can be found below. > > > > Regards, > > Greg > > > > > > On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Greg for your further reply and the discussions. > > *Good to know that you do see a need for the extensions for the > direct-mode packet loss detection and the authors are actively working on > an alternate methods using BFD (as you mentioned below).* > > GIM3>> As you've recognized, in draft-mirmin-bfd-extended > we > build an integrated OAM based on the lightweight Fault Management protoco= l > with optional Performance Monitoring, based on RFC 6374. RFC 6374, in tur= n, > provides a rich set of performance measurement methods, including direct > loss measurement. > > Please see replies inline with =E2=80=A6. > > *From: *Greg Mirsky > *Date: *Monday, November 30, 2020 at 11:30 AM > *To: *Rakesh Gandhi (rgandhi) > *Cc: *Gyan Mishra , IETF IPPM WG , > James Guichard , ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > spring@ietf.org , Greg Mirsky > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh, > > thank you for the continued discussion. I appreciate your responses. I am > still not convinced of the value these documents add. Please find my > follow-up notes in-line below under the GIM2>> tag. > > Regards, > > Greg > > On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Gyan and Greg for your review comments and discussions. Please > see inline replies with =E2=80=A6 > > *From: *Gyan Mishra > *Date: *Wednesday, November 25, 2020 at 12:34 PM > *To: *Greg Mirsky > *Cc: *IETF IPPM WG , James Guichard < > james.n.guichard@futurewei.com>, Rakesh Gandhi (rgandhi) < > rgandhi@cisco.com>, ippm-chairs@ietf.org , > spring-chairs@ietf.org , spring@ietf.org < > spring@ietf.org> > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh > > I have been following this thread and to help progress the discussion I > would like to provide some comments in-line Gyan> > > Thanks > > Gyan > > On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky wrote= : > > Hi Rakesh, > > thank you for the response to my comments. Please find my follow-up notes > in-lined below under the GIM>> tag. > > Regards, > > Greg > > On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the comments. > > Please see replies inline with =E2=80=A6 > > *From: *ippm > *Date: *Friday, November 6, 2020 at 11:18 AM > *To: *James Guichard > *Cc: *spring@ietf.org , ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > IETF IPPM WG > *Subject: *Re: [ippm] [spring] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Dear Chairs of the SPRING and IPPM WGs, Authors, et al., > > I've found myself in the situation when two related drafts are in the WG > APs in the SPRING and IPPM WG (with the possibility that expertise from t= he > third WG, BFD WG, might be desirable to review the "liveness monitoring")= . > Because these drafts are closely related, I've decided to combine my > questions and comments in a single thread. I hope that would be acceptabl= e > and considered by the SPRING WG as well as IPPM WG. > > Usually, the bar for the adoption of a document can be evaluated by > answers to these three questions: > > - Is the document(s) reasonably well-written > > I've got surprised that the drafts don't use the terminology from RFC 465= 6 > and 5357 and introduce their own terminology for Session-Sender and > Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are > used in the documents without proper definitions. Other than that both > drafts are readable and reasonably well-written. > > We are ok to change Sender to Session-Sender and Reflector to > Session-Reflector if it helps. > > > > GIM>> I believe that the consistency in terminology between the core RFC > and what is intended as its extension is not only helpful to a reader but= , > to the best of my understanding, is required for IETF specifications. But= I > don't think that switching the terminology will fix the fundamental issue > with the proposal. The operation that is required from the remote entity, > whether it is referred to as responder or Session-Reflector, is not defin= ed > in Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion= , > the behavior required, as described in the draft, cannot be characterized > as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely > new protocol that, if there's a need in the new PM OAM protocol, must be > properly defined. > > Gyan> I am in complete agreement with Greg about terminology and > consistency. The problem with inconsistency is that that you are not > following well known normative references required to understand the > specification leading to confusion and misunderstanding of the > specification. The goal should be clear and concise in terminology and > verbiage. > > Agree. Will address the terms from RFC 5357 in the next revision. > > There are many existing RFCs that use term =E2=80=9CLink=E2=80=9D (e= .g. RFC 5613, > 5340, 8330, etc.) and term =E2=80=9CCongruent Path=E2=80=9D (e.g. RFC 592= 1, 6669) without > defining them. I suspect it is because these are well-known terms. Having > said that, we can add a reference for them if it helps. > > GIM>> Thank you for listing these RFCs. I think I need to clarify my > questions. While a reference to any of RFCs you've mentioned, I don't thi= nk > that will address my concern. In reviewed documents, "Link" is capitalize= d > while referenced RFCs used the lower case form for the term "link". Can > these be used interchangeably? Do they refer to the same network object? > > Now I'll try to illustrate my concern with using the term "congruent path= " > in these drafts (using ASCII-art): > > C---------D > > / \ > > A----B E-----F > > \ / > > G------------H > > Consider an SR tunnel from A to F that traverses the network as > A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of > "congruent" as "two figures or objects are congruent if they have the sam= e > shape and size, or if one has the same shape and size as the mirror image > of the other", it looks as the path A-B-G-H-E-F is congruent to that SR > tunnel. But a packet of an active OAM intended to monitor a flow over the > SR tunnel is out-of-band relative to that flow and will not produce any > meaningful measurement. Of course, for the case of the extensions in draf= ts > *-twamp-srpm, direct loss measurement can be performed, as information > collected from node F and packets that collect the counters are not > required to be in-band with the monitored flow. So, this example, in my > opinion, illustrates two of my concerns: > > =C2=B7 using a congruent path for active performance measurement, > e.g., TWAMP or TWAMP Light, may produce information that does not reflect > the condition experienced by the monitored flow. It seems that the > terminology should reflect the fundamental requirement of ensuring that > active OAM test packets are in-band with the monitored flow. > > =C2=B7 there are no technical requirements to justify using in-ba= nd > test packets for direct packet loss measurement. In fact, using the in-ba= nd > method for collecting in-profile counters leads to a waste of bandwidth, > which may have a negative impact on services that require low-latency > and/or low packet loss. As demonstrated in this example, direct packet lo= ss > can be performed using an out-of-band mechanism, e.g., SNMP queries, > Netconf notifications based on YANG data model. > > > - Does the document solve a real problem? > > No, it appears that these drafts define a new performance measurement > protocol for the purpose of combining OWAMP and TWAMP functionality and > adding the ability to collect counters of "in-profile" packets. I couldn'= t > find sufficient technical arguments for using a PM protocol instead of, f= or > example, extending the existing OAM mechanisms like ICMP. > > Gyan> This may sound basic but is a very critical subject going down th= e > same lines of clarity in verbiage so their is no misunderstanding. > =E2=80=9CCongruent=E2=80=9D by definition means shape of an object and i= f you super > imposed two objects on top of each other they fit perfectly and the edges > coincide identically. The problem with congruent is that it is based on > the shape and that shape could be a mirror image or reflection which may > not be exact. So when referring to a SR-TE path taken this could lead to > confusion as to path taken if it=E2=80=99s the same path or congruent whi= ch is > vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here ther= e is criticality > as to the path being referenced in terms of in-band versus out-of-band. = I > agree that for direct in band packet loss measurement can be done via > existing OAM mechanisme via ICMP. > > Ok, we will find an appropriate term for =E2=80=9Csending packets o= n the > same path as data traffic=E2=80=9D. > > Extending ICMP for direct-mode loss measurement is outside the scop= e > of this draft. But good to see the agreement for the direct in band packe= t > loss measurement to be done (albeit by some other means). > > GIM2>> I feel that you misunderstand my position in regard to the use cas= e > these four documents try to solve. I don't recall that I've stated that > "direct in-band packet loss measurement" requires any additional > standardization work. The Direct Measurement TLV has solved that for STAM= P > and draft-ietf-ippm-stamp-option-tlv is now in the RFC Editor's queue. I > cannot find any valid technical reason to re-open this and measure the > direct packet loss in a slightly different way. I must point out that a > claim that using fixed positions for the direct packet loss optimizes > performance does not stand for cases (Section 4.2.1 and 4.2.2 of > draft-gandhi-spring-stamp-srpm) when the return path is specified in the > Return Path TLV and, as I understand it, in some cases even the second TL= V, > Node Address TLV, is used. Thus, it is clear that the proposed new method > of direct packet loss measurement does not offer any significant benefits > comparing to the STAMP's Direct Measurement TLV and appears nothing but > superfluous. > > The direct-mode packet loss use-case is typically for the forward > direction packet loss. And this does not use the return path TLV. We can > clarify that in the draft. > > GIM3>> Clarification would be very helpful as your latest note might be > interpreted that the proposed mechanisms are not applicable in the case o= f > a bi-directional SR tunnel. > > There is a requirement to measure performance delay as well as > synthetic and direct-mode packet loss in segment-routing networks. OWAMP > and TWAMP protocols are widely deployed for performance delay and synthet= ic > packet loss measurement today. I am not sure extending ICMP for LM is a > good option here. > > GIM>> I agree with the requirements you've listed (though the SPRING WG > OAM requirements document > has > been abandoned and expired 3+ years ago). I believe that there's no > sufficient technical reason to use OWAMP/TWAMP for exclusive direct packe= t > loss measurement. > > Gyan> Agreed > > There is definitely a need to do direct-mode loss measurement in > IP/SR networks, as RFC 6374 mechanisms are for MPLS networks. Note that > there was an attempt to extend BFD for direct-mode loss measurement for > this purpose using RFC 6374 loss measurement message (see > draft-mirmin-bfd-extended-03). > > GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended > in the > past tense. The work and discussion of the proposal continues and the new > version will be published soon. > > * Ok, so you do see a need for the extensions for the direct-mode > packet loss detection and the authors are actively working on an alternat= e > methods using BFD. * > > > - Is the proposed solution technically viable? > > There are too many unaddressed aspects, particularly the risk introduced > by the protocol on network security, to comprehensively evaluate the > proposed solution. > > About your comment on zero checksum, this is described in Security > section in RFC 6936. We will add reference to this RFC in our Security > Section as well. This is only specific to the UDP port locally provisione= d > in the domain by the operator for TWAMP. Other than this, I did not find > any other security related issue in your review below. > > GIM>> I don't think that a mere reference sufficiently explains why the > use of zero UDP checksum in IPv6 header is not decremental, does not crea= te > a security risk for the protocol. > > Gyan> Agreed 0 UDP MIMA security threats and that you need to > thorough vetting of RFC 6936. > > Yes, will add in the next revision. Hope we can work together on > needed text. > > To summarize my review of these two drafts: > > - these propose a new protocol, not an update or enhancement of the > TWAMP-like protocol; > > The probe and response messages defined in [RFC 5357] are used for > delay measurement and synthetic packet loss. The direct-mode packet loss > messages are defined in draft-gandhi-ippm-twamp-srpm > that > match these delay measurement messages. As stated, > draft-gandhi-ippm-twamp-srpm > defines > =E2=80=9Cextensions=E2=80=9D for TWAMP Light. > > GIM>> I cannot find where RFC 5357 defines "the probe and response > messages". Could you give a more specific reference or provide the text > that, in your opinion, defines such messages? But I'm more concerned with > the direction of "extending" non-protocol referred to as "TWAMP Light". A= s > a contributor to BBF's TR-390, I'm have learned how different are existin= g > implementations of TWAMP Light. And that is also noted in EANTC > Multi-Vendor Interoperability 2019 white paper > . > The status of TWAMP Light is explained in RFC 8545 and I cannot see that = it > can be used as a foundation of any standard. > > Gyan> I don=E2=80=99t see the probe a d response messages in TWAMP RFC = 5357 > > Agree to use term test-packet from RFC 5357. > > =C2=B7 several parts of the proposed protocol, e.g., Zero UDP che= cksum > in IPv6, require detailed security analysis, which is currently absent; > > Gyan> Agreed > > Please see previous reply. > > This is specified in RFC 6936 Security Section. We will add referenc= e > to this RFC in our Security Section as well. This is only specific to the > UDP port locally provisioned in the domain by the operator for TWAMP. > > GIM>> I've noted above that a simple reference does not sufficiently > explains why the use of zero UDP checksum in IPv6 header is not > decremental, does not create a security risk for the protocol. I believe > that the proposal to use zero UDP header checksum requires extensive > analysis, using the analysis provided in RFC 6936. > > Gyan> Completely Agree > > Please see previous reply. > > > - I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on > the Informational track even though it is essential to the new protoco= l as > it defines its key elements > > This was to address your previous comment quoted as: > > =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Information= al > > track is more appropriate for this specification.=E2=80=9D > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > Having said that, we are ok to change to PS. > > GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. > If anyone is interested in standardizing an "extension", I'd expect that > they first define the base specification to which the extension applies. = I > might have missed the definition of TWAMP Light protocol in the draft. Co= uld > you point to the definition, for example, of the Authenticated mode in > TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? > > Gyan> Agreed > > The Appendix I of RFC 5357 does have information on the > Authentication mode. As specified there, this is based on user configured > parameters. > > =C2=B7 I believe that draft-gandhi-spring-twamp-srpm should be > anchored at IPPM WG as it does introduce the new PM protocol. > > The TWAMP Light extension draft-gandhi-ippm-twamp-srpm > is > already in IPPM WG. The SPRING draft only defines SR PM procedures. > > Below, please find my detailed comments, questions on these drafts: > > - draft-gandhi-spring-twamp-srpm > > I have several questions about the relationships between this draft and > Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light has > been mentioned. The nature of the TWAMP Light and what is required to mak= e > it a standard is well-explained in Section 4 of RFC 8545 > (apologies for the long > quote): > > "TWAMP Light" is an idea described in Appendix I ("TWAMP Light > (Informative)") of [RFC5357]; TWAMP Light includes an unspecified > control protocol combined with the TWAMP-Test protocol. In > [RFC5357], the TWAMP Light idea was relegated to Appendix I because > TWAMP Light failed to meet the requirements for IETF protocols (there > are no specifications for negotiating this form of operation and no > specifications for mandatory-to-implement security features), as > described in Appendix A of this memo. See also [LarsAD] and > [TimDISCUSS]. > > Since the idea of TWAMP Light clearly includes the TWAMP-Test > component of TWAMP, it is considered reasonable for future systems to > use the TWAMP-Test well-known UDP port (whose reallocated assignment > is specified in this document). Clearly, the TWAMP Light idea > envisions many components and communication capabilities beyond > TWAMP-Test (implementing the security requirements, for example); > otherwise, Appendix I of [RFC5357] would be one sentence long > (equating TWAMP Light with TWAMP-Test only). > > Since we don't have an IETF document that addressed these open questions= , > I don't think we can have a draft that proposes extensions to a > non-standard mechanism (Appendix is for Informational material, as I > understand it) on the Standard track. > > Gyan> Agreed > > The procedure for using the RFC 5357 defined messages in TWAMP Ligh= t > configuration mode is defined in the corresponding spring drafts. It also > describes the provisioning model. > > GIM2>> If a return path can be provisioned for TWAMP Light, why the same > method of controlling a test session cannot be used for STAMP? > > It is not expected that all STAMP TLV extensions need to be > supported for TWAMP Light using provisioning. > > This was to address your previous comment quoted as > > =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Information= al > > track is more appropriate for this specification.=E2=80=9D > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > Having said that, we are ok to change to PS as you mentioned above. > > BTW, despite only difference of fixed vs. variable length payload in > STAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and = it > uses the same approach of provisioning as defined in this draft). Hence, > security considerations for STAMP and TWAMP Light are not different. Note > that both STAMP and TWAMP Light have authenticated messages defined for > Security purpose. > > GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the > light, simpler, version of TWAMP-Test component of TWAMP protocol. I cann= ot > find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mo= de > of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the > discussion of "extension" to TWAMP Light. > > The Authentication information is user-configured as shown in > Section 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described = in > Appendix I of RFC 5357. > > Now a number of more specific questions. > > draft-gandhi-spring-twamp-srpm: > > - In the Introduction it is stated that: > > The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides > simplified mechanisms for active performance measurement in Customer > IP networks by provisioning UDP paths and eliminates the need for > control-channel signaling. > > I can not find where, either Appendix I or TR-390, "eliminated the need > for control-channel signaling". Also, could you point where the reference= d > documents describe "provisioning UDP paths"? > > The Appendix I of RFC 5357 has following text. We can reword and mat= ch the exact text if you prefer. > > > > =E2=80=9CThis example eliminates the need for the TWAMP-Control protocol,= and > > assumes that the Session-Reflector is configured=E2=80=9D > > GIM>> I think that the text you're proposing is even more confusing. It i= s > not clear which example the sentence is referring to. Also, what is the > basis for such an assumption? > > This is the exact text from RFC 5357 Appendix I. Please go through > the entire Section in that RFC 5357 to avoid =E2=80=9Cout of context=E2= =80=9D discussion. > > > - It appears that the last paragraph in the Introduction describes the > relationship with Appendix I of RFC 5357: > > The procedure uses the mechanisms defined in [RFC5357] > (TWAMP Light) and its extensions for Performance Measurement. > > I think that the reference must be to Appendix I, not RFC 5357. Also, > could you please specify which extensions of TWAMP Light have been used i= n > this draft? > > We can add the Appendix I as reference in the next revision. > Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add this > reference. > > GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a > normative reference while it is, by its nature, an Informational document= . > > If approved, it is fine to have informational draft/RFC in a > normative reference. But RFC 5357 is PS. > > > - In Section 2.3 describing the reference model is noted: > > The probe response message is typically sent to the sender node R1. > > In which scenarios the reflector acts differently? How such behavior is > related to the behavior of a TWAMP Session-Reflector, as defined in RFC > 5357? > > Do you prefer we remove =E2=80=9Ctypically=E2=80=9D from the sentenc= e? > > GIM>> If that fits into the operational model of the new protocol you're > defining. > > > - Also in Section 2.3 a Link is mentioned as an element directly > connecting nodes in the presented reference model. Could you clarify w= hat > is a Link? Is it always a physical connection between two systems or a > virtual? > > Both, please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known= term used in > many existing RFCs (please see RFC 5613, 5340, 8330). > > GIM>> Thank you for the references. I couldn't find a definition of an > object "Link" (capitalized) but only "link" (lower case). Hence, since th= e > draft consistently uses the capitalized form, I consider it to be somethi= ng > else, something different from a link. > > Ok, we can change Link to link in the next revision to avoid > confusion. > > > - In Section 3 behavior of the reflector described as > > ... no PM state for delay or loss measurement need to be created on th= e > reflector node R5. > > That is in contradiction to the behavior of a TWAMP Session-Reflector as > defined in RFC 5357. Could you provide a reference to an IETF standard > where this behavior is defined? Also, how, without creating a state at th= e > Session-Reflector, to achieve one-way delay and synthetic loss measuremen= t > on a bidirectional SR tunnel? > > Gyan> Valid point > > Bidirectional SR tunnel may have an SR state but the statement abov= e > is that no PM (i.e. TWAMP Light) protocol session state is created for it= . > We can clarify in the next revision. > > GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one > option. I am well-familiar with the implementation that uses the stateful > mode. > > What information stateful PM need to maintain in the state on the > reflector? Doesn=E2=80=99t that cause scale issues. We can add in the dra= ft you if > there is anything specifically needed in the spec. > > GIM3>> RFCs 5357 and 8762 are clear about what information must be > maintained by a Session-Reflector. The Session-Reflector must have > knowledge of the test session state and count reflected test packets. The > value of such a counter must be copied in the Sequence Number field of th= e > reflected packet. Thus the method enables the measurement of the one-way > packet loss metric. > > Quoting the text from Appendix I in RFC 5357. We can quote the text > as is. > > =E2=80=9CIn the case of TWAMP Light, the Session-Reflector does not neces= sarily have knowledge of the session state. =E2=80=9C > > GIM>> By the informational nature of Appendix I, the text is not > normative. I am familiar with the implementation of TWAMP Light which doe= s > maintain the session state and thus supports one-way packet loss > measurement. If you require that the remote node does not maintain the > state, the draft must define that as part of the specifying the behavior = of > the protocol. > > Ok, we can discuss what information is to be maintained in that > state on the reflector for synthetic packet loss. We can add appropriate > text if you can help please. > > GIM2>> I don't see any reason to do that as that already defined in RFC > 8762 and draft-ietf-ippm-stamp-yang > > > Ok. > > =C2=B7 Further, in Section 3 the selection of UDP port explained = as > the following: > > As specified in [RFC8545], the reflector > supports the destination UDP port 862 for delay measurement probe > messages by default. This UDP port however, is not used for loss > measurement probe messages. > > To the best of my understanding, as one of the contributors and Editors o= f > RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflect= or > without excluding any type of measurement. Besides, in TWAMP delay and > packet loss are measured in the same test session, using the same flow of > TWAMP-Test packets. > > Gyan> Agreed > > Yes, we can use port 862 for both delay and synthetic packet loss = =E2=80=93 > they are using the same test packet. There is no change proposed in the > draft. > > GIM2>> Packet delay and synthetic packet loss measurements are already > supported in RFC 8762. Are you proposing a new protocol to duplicate the > STAMP functionalities? > > As mentioned, the extensions defined are for the direct-mode packet > loss measurement for TWAMP Light and STAMP. > > The packet loss in existing RFC 5357 refers to synthetic loss as > there is no support for direct-mode loss in RFC 5357. We can change the > text to clarify as =E2=80=9CThis UDP port however, is not used for direct= -mode loss > measurement probe messages.=E2=80=9D > > GIM>> I've found that there's some misconception in the draft. RFC 8545 > re-assigned UDP port 862 not for "delay measurement probe messages" but f= or > TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, > packet loss, reordering (RFC 4737 defines packet reordering metric), and > packet duplication measurement. > > > - Then the draft states that > > The sender uses the UDP port number following the guidelines specified in > Section 6 in [RFC6335]. > > Could you point to the guidelines that a user can use when selecting a UD= P > port number of a test session? > > Gyan> Good point > > Please see section 6 in [RFC6335]. We can cite the range which will > be the same as used in [RFC8762]. This was also discussed earlier. > > https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ > > GIM>> I've looked through Section 6 but I don't find anything specificall= y > applicable to this draft we're discussing. If the protocol to use UDP por= t > numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then = it > seems that stating that explicitly would be the best way. > > This would be, User Ports and Dynamic Ports ranges, which are defin= ed in [RFC6335 ]. Yes, we can add this= text. > > > - At the closing of the paragraph, we read that > > The number of UDP ports with PM functionality needs to be minimized due > to limited hardware resources. > > Does a UDP port number pose PM functionality? How it is assigned to the > port number? > > UDP ports are user configured for delay and direct-mode loss PM as > described in Section 3.1. > > GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss > measurement uses port number different from the one used by a TWAMP-Test > packet, in my opinion, is another indication that this is the definition = of > a different from TWAMP Light PM OAM protocol. > > If we add a field in the packet then UDP port 862 may be used along > with the new field. But it will require extra processing in hardware. It = is > better to use a different UDP port for processing efficiency in hardware. > > > - Following the above-quoted text, in Section 3 is noted: > > For Performance Measurement, probe query and response messages are > sent as following: > > Could you clarify if the listed further procedures deviate from > OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for > Session-Sender and Session-Reflector respectively? > > Probe messages follow the same procedure as defined in RFC 4656 and > RFC 5357. > > GIM>> All messages, i.e., TWAMP-Test packets as well as the defined > in draft-gandhi-ippm-twamp-srpm? > > Yes, unless otherwise specified in the > draft-gandhi-ippm-twamp-srpm. > > > - for both delay and loss measurements draft requires test packet be > transmitted on a congruent path: > > the probe messages are sent on the > congruent path of the data traffic by the sender node > > It is not clear what "the congruent path" means. The definition > of congruency in geometry tells us that an object B is congruent to objec= t > A if it has the same shape and size, but is allowed to flip, slide or tur= n. > How a path can be congruent to another path? > > Gyan> Agreed. The use of congruent in the context of pathing is > confusing as the path being addressed may not be reflected accurately by > the term congruent. > > As replied above. > > There are many existing RFCs that use term Congruent Path (e.g. RFC > 5921, 6669) without defining them. I suspect it is because it is well-kno= wn > term. Having said that, we can add a reference for it if it helps reader. > > GIM>> I cannot assume what was the context of these RFCs. I've sketched a > network diagram above to illustrate that a "congruent path" may well lead > to out-of-band path. Is that the intention of the authors of the draft to > use this protocol out-of-band? > > As replied above. > > > - The last paragraph in Section 3 refers to work on iOAM: > > The In-Situ Operations, Administration, and Maintenance (IOAM) > mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for > SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM > information such as timestamp in-band as part of the data packets, > and are outside the scope of this document. > > Is iOAM in the scope of this specification? What are the relationships > between iOAM and draft-gandhi-spring-twamp-srpm? > > As mentioned in the draft, IOAM is outside the scope. > > GIM>> Yes, but it appears that references to the two IOAM-related drafts > have some purpose. What is it? How are these drafts related > to draft-gandhi-spring-twamp-srpm? > > We can remove them if it is confusing. It is informational text (wa= s > added to address a review comment). > > > - Section 3.1 presents an example of the provisioning model but puts > the definition of the provisioning model outside the scope. Is there a= n > accompanying specification that defines the provisioning model that ca= n be > used in multi-vendor deployment? Could that be YANG data model? What i= s the > relationship with draft-ietf-ippm-twamp-yang > ? Would the > TWAMP YANG data model be augmented? > > Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yan= g > and add any > missing items in a separate draft. We can also add a reference in this > draft. > > GIM>> I think that theremust be some discussion on how the new protocol i= s > configured. If TWAMP YANG data model can be augmented, I'd expect that > being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anythi= ng > about the configuration of the protocol. > > The Yang model extensions are not in the scope of this draft > > > - Section 4.1 states that a new message is introduced to perform the > Loss Measurement in this protocol Why the capability of TWAMP to measu= re > the loss in one-way and two-way is not sufficient? > > Existing TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D= loss > measurement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clar= ify. > > GIM>> True, direct loss measurement, in fact, is not active measurement > and thus is outside the scope of Two-Way Active Measurement Protocol > (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, > passive measurement method and fetching counters can be done using numero= us > methods, e.g., SNMP, Netconf > > RFC 7799 does not say using Test-packets to collect counters for > direct-mod loss measurement is passive. > > GIM2>> Per RFC 7799, injecting in-band test packets is the characteristic > of an active measurement method. Using out-of-band transport, e.g., SNMP > queries, would be an example of a passive measurement method. > > Ok, so you answered your own question that the direct-mode packet > loss extension defined is =E2=80=9Cactive measurement=E2=80=9D method. > > > - Section 4.1.1 requires that > > The Destination UDP port cannot be used as Source port, since > the message does not have any indication to distinguish between the > query and response message. > > Does that imply that the Destination UDP port used for the Delay > measurement is unique throughout the particular domain? > > Gyan> Good question > > Yes, it is unique in the domain. > > This is user-defined and is up to the user what UDP port to provisio= n > in a domain. > > GIM>> So, can user configure a port number from the User Ports range? Or, > can the same port number be used on the same system for a number of test > sessions? I find the use of UDP port numbers being underspecified. > > > - Section 4.1.2 of RFC 5357 does not define "the delay measurement > message" but refers to the definition of the Session-Sender's test pac= ket > in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test > packet format to perform both delay and packet loss measurement. > > Ok, we can update the text in the next revision to indicate exact > name from the RFC 4656. We can also add text to include synthetic packet > loss. > > GIM>> I think that making it explicit would help. Also, that will > highlight what is being introduced by *twamp-srpm drafts is, in fact, a n= ew > protocol to perform synthetic packet loss measurement. > > No, it does not change anything for synthetic packet loss. > > > - Can you explain how "the DM probe query message contains the payload > format defined in Section 4.2.1 of [RFC5357]" when the referenced sect= ion > of RFC 5357 defines the format of a Session-Reflector's test packet? > > We can update the text in the next revision to indicate query format > name from RFC 5357. > > GIM>> I cannot find any reference to a query format in RFCs 4656/5357. > Could you please quote from any of these documents? > > It is test-packet, we will use RFC 5357 term. > > > - Can clarify the applicability of RFC 6038 and the symmetrical packet > size? Is it required? Can it be non-symmetrical? > > Yes. Please see section 4.1.1 and quoted below: > > =E2=80=9CFor symmetrical size query and response messages as defined in [= RFC6038],=E2=80=9D > > GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the > symmetrical test packets. Since *-twamp-srpm proposals do not use > TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about > that either (in part because RFC 6038 came later), I don't see that there= 's > any certainty in what is the sze of a test packet used in the direct-loss > measurement. > > The test-packets as defined in these existing RFCs are used for > delay and synthetic packet loss. The direct-mode test-packets are defined > in this draft. > > GIM2>> This draft defines only a new packet format for the direct packet > loss measurement. For STAMP such a mechanism is clearly superfluous given > the Direct Measurement TLV is already defined. > > As replied earlier. > > > - Can you clarify the use of the timestamp format, NTP or PTPv2? It is > not clear which is the default, mandatory or optional. > > This is same as TWAMP. There is no change. > > GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for > *-twamp-srpm? > > No change in existing in what is there in RFC 5357 and RFC 8186. > > > - Also, is "hardware support in Segment Routing networks" of the PTPv2 > format required, guaranteed, or something else? > > Hardware timestamps are recommended for SR use-cases. We can change > the sentence. > > GIM>> Perhaps you can propose some text, that would be helpful. > > Ack. > > > - Section 4.1.1.1 stated that > > A separate user-configured > destination UDP port is used for the delay measurement in > authentication mode due to the different probe message format. > > Can that be interpreted that there could be concurrent authenticated and > unauthenticated test sessions using this protocol? Would different > authentication methods require using unique destination UDP port numbers? > > Yes, and Yes, and these are based on provisioning. > > GIM>> But that requirement is far outside the TWAMP, as defined in RFC > 5357. > > Some Session-Sender can use authenticated and some not. It is part > of RFC 5357. > > > - Section 4.1.2 by introducing the dedicated Loss measurement packet > format, effectively modifies the behavior defined in RFC 5357 for > Session-Sender and Session-Reflector. But the document does not state = that. > Can you clarify whether this specification changes the behavior of a > Session-Sender and Session-Reflector as defined in RFC 4656 and RFC 53= 57 > respectively for the support of packet loss measurement? > > The direct-mode loss defines new procedure for sender/reflector to > collect traffic counters, as opposed to timestamp. The rest is the same a= s > RFC 4656 and 5357. > > GIM>> I cannot agree with your statement " The rest is the same as RFC > 4656 and 5357" because the sender's direct-loss format does not have Erro= r > Estimate field, Thus, a reflected packet does not have Sender's Error > Estimate, nor Error Estimate of the reflector. And that, in my opinion, i= s > another clear indication that *twamp-srpm drafts define a new protocol, > separate from OWAMP/TWAMP. > > That field is specific to timestamps and would not apply to > counters for direct-mode loss measurement. > > > - And a similar question about the use of the separate UDP port number > for the authenticated of the packet loss measurement. > - A couple of question to the following text in Section 4.1.3: > > The local and remote IP > addresses of the link are used as Source and Destination Addresses. > They can also be IPv6 link local address as probe messages are pre- > routed. > > - What are the addresses of a link? > > I am assuming this well-known (e.g. RFC 2328). > > GIM>> I am not familiar with the term "pre-routed". What does it mean? > > Ensure that packets are routed over the link. > > > - In which scenarios an IPv6 LLA can be used? > > I am assuming this is well-known (e.g. RFC 5613). > > GIM>> So, LLA may be used as the source and destination addresses when > testing an SR tunnel? > > As mentioned this is for links. > > > - Also, could the use of a routable destination IP address be used as > a DDOS attack vector? Consider the scenario when an attacker genera= tes > SR-encapsulated packets with the destination IP address other than = any of > the SR-terminating nodes. Such a packet will be routed, correct? Th= at does > appear as a security threat, would you agree? > > Absolutely do not agree. It is no different than IP routed TWAMP > packet as defined in [RFC5357]. > > GIM>> You don't agree that the processing described cannot happen because > of laws of physics or it wouldn't happen because no one will think of tha= t? > If the latter, I think that that is security threat. > > There is no new threat like you have mentioned. > > GIM2>> Hmmm, but how the integrity of TLVs proposed > in draft-gandhi-ippm-stamp-srpm can be protected? These are not protected > by HMAC as presented in figures 3 and > 5. > > > The extensions do not change the processing of these existing TLVs > defined for HMAC. We can add text to indicate this. > > > - Section 4.1.4.2 references Figure 5 that, as I understand it, > displays the format of a probe query message. In figure two references= to > RFC 5357 are provided - a section that references RFC 4656 OWAMP defin= ition > of the Session-Sender test packet, and a section that defines the > Session-Reflector's reflected packet. Which of the two is used for the > delay measurement in the proposed protocol? > > The probe query packet in the Session-Sender text packet. We can > update the name. > > - Section 4.2.1 states that > > In one-way measurement mode, the probe response message as defined in > Figure 6 is sent back out-of-band to the sender node ... > > Could you clarify how the responder controls that the response packet is > sent not in-band but out-of-band? > > Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This i= s > existing behaviour for out-of-band. > > GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines > another new protocol OWAMP Light. And it is not clear what you reference = as > "this is existing behavior". Is it to reference behavior of TWAMP test > packet? But the behavior of the TWAMP-Test protocol by itself is neither > in-band, nor out-of-band. It is the encapsulation of the TWAMP test packe= t > that makes it either in-band or out-of-band. > > Right. > > > - How's the method described in Section 4.2.3 is different from the > method described in RFC 8403 ? > What is distinctly unique about the loopback mode proposed in the sect= ion? > > There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403= . > > GIM>> So, you believe that proposing to use the > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000d02cca05b5bc855d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Rakesh

    Please see in-line=C2=A0

    On Sat, Dec 5, 2020 at 10:32 AM Rakesh Gan= dhi (rgandhi) <rgandhi@cisco.com> wrote:

    Hi Gyan,=

    =C2=A0

    Thanks for your review= comments. Please see inline with <RG4>=E2=80=A6=

    =C2=A0

    From: Gyan Mishra <hayabusagsm@gmail.c= om>
    Date: Saturday, December 5, 2020 at 1:16 AM
    To: Greg Mirsky <gregimirsky@gmail.com>
    Cc: Greg Mirsky <gregory.mirsky@ztetx.com>, IETF IPPM WG <ippm@ietf.org>, James Guich= ard <james.n.guichard@futurewei.com>, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>,= ippm-chairs@ietf= .org <ippm= -chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, spring@ietf.org &= lt;spring@ietf.org= >
    Subject: Re: [spring] [ippm] WG Adoption Call for h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11<= /u>

    Hi Rakesh=C2=A0

    =C2=A0

    Had a general question.

    =C2=A0

    I read through the draft again and a question came t= o mind as this draft is Standards Track, what new is being introduced other= then a procedure of how to use TWAMP in SR networks SR-MPLS which reuses t= he MPLS data plane and SRv6 which used the IPv6 data plane.=C2=A0 I don=E2=80=99t believe there exists =C2= =A0a Standards track draft procedure for how to use STAMP over IP network o= r MPLS network as an example. =C2=A0

    =C2=A0

    Section 4.1.4 describes SR-MPLS use case and SRv6 us= e case.=C2=A0 As there appears to be nothing new introduced such as a new I= ANA TLV or code point or even a special SID code point =C2=A0for TWAMP, all= basic vanilla SR, that without this draft you could run STAMP, TWAMP, OWAMP over SR which has existed for a while now. = =C2=A0

    =C2=A0

    What is the new invention here?

    =C2=A0

    <RG4> SPRING dra= fts define the procedure for using TWAMP Light and STAMP test-messages for = SR path and links. The corresponding IPPM drafts define the extensions need= ed for them. The SPRING drafts also use the extensions for them defined in the corresponding IPPM drafts. The extensio= ns are needed for (1) in-band response request e.g. for two-way mode for li= nks and SR path, (2) Return path for SR e.g. when using bidirectional SR Pa= th, and (3) for collecting TX and RX traffic counters in-band for direct-mode loss measurement.

    =C2=A0Gyan> Understood.=C2=A0= Just to see if a precedence has already been set if you point me another c= ase where Spring or any other WG RFC Standards Track that =C2=A0has defined= procedures to use IPPM extensions.=C2=A0 If this is the first and may also= set a new precedent, =C2=A0I think it=E2=80=99s a valid WG discussion.<= /u>

    Sorry but I may have missed something.=

    =C2=A0

    My thoughts are at most this be a BCP or I am thinki= ng informational draft would be appropriate.

    =C2=A0

    <RG4> Given abov= e context, if WG thinks that any of the drafts should be BCP or Information= al or Experimental, we can update the draft accordingly.

    Gyan> Agreed.=C2=A0 Thank you= =C2=A0

    Thoughts?

    =C2=A0

    Gyan

    =C2=A0

    On Thu, Dec 3, 2020 at 12:51 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

    Hi Rakesh,

    thank you for the continued discussion. You can find= my follow-up notes in-line below under GIM3>> tag. I felt that one c= omment is at the root of our different views on what is considered to be a = problem that drafts solve. You've said:

    <RG3> As mentioned, the extensions defined are= for the direct-mode packet loss measurement for TWAMP Light and STAMP.<= /u>

    But draft-ietf-ippm-stamp-option-tlv, currently in=C2=A0 Submitted to IESG = for Publication WG state according to IETF datatracker, includes Section 4.= 5 Direct Measurement TLV. It is noted in the section:

    =C2=A0 =C2=A0The Direct Measurement TLV enables coll= ection of the number of in-
    =C2=A0 =C2=A0profile packets, i.e., packets that form a specific data flow,= that
    =C2=A0 =C2=A0had been transmitted and received by the Session-Sender and Se= ssion-
    =C2=A0 =C2=A0Reflector, respectively.=C2=A0 The definition of "in-prof= ile packet" is
    =C2=A0 =C2=A0outside the scope of this document and is left to the test ope= rators
    =C2=A0 =C2=A0to determine.

    =C2=A0

    <RG4><= /u>

    Hi Greg,=

    The motivation has bee= n there in the draft-gandhi-ippm-stamp-srpm, Section 1. Copied below for th= e convenience.

    =C2=A0

    =C2=A0=C2=A0 The STAMP message with a TLV fo= r "direct measurement" can be used for

    =C2=A0=C2=A0 combined Delay + Loss measureme= nt [I-D.ietf-ippm-stamp-option-tlv].

    =C2=A0=C2=A0 However, in order to use only f= or loss measurement purpose, it

    =C2=A0=C2=A0 requires the node to support th= e delay measurement messages and

    =C2=A0=C2=A0 support timestamp for these mes= sages (which may also require clock

    =C2=A0=C2=A0 synchronization).=C2=A0 Further= more, for hardware-based counter collection

    =C2=A0=C2=A0 for direct-mode loss measuremen= t, the optional TLV based processing

    =C2=A0=C2=A0 adds unnecessary overhead (as c= ounters are not at well-known

    =C2=A0=C2=A0 locations).

    =C2=A0

    Thus I cannot see any technical need for the introdu= ction=C2=A0of yet another way of direct loss measurement in STAMP. As for t= he case of TWAMP Light, I believe that there's no sufficient evidence t= hat the proposed direct loss-measurement measurement method benefits existing implementations of TWAMP Light. Also, historicall= y, all extensions applicable to TWAMP Light have been introduced through ex= tending TWAMP proper, i.e., extending TWAMP-Control and TWAMP-Test. The way= of "extending" TWAMP Light presented in the drafts we are discussing is, in my opinion, in violation of RFC 535= 7.

    =C2=A0

    <RG4> The IPPM W= G Informational draft on TWAMP Light direct-mode loss measurement, defines = the message format and corresponding SPRING draft defines the procedure for= using that. It is not clear to me how providing an informational draft gandhi-ippm-twamp-srpm is violating RFC 5357.

    =C2=A0

    Thanks,<= /span>

    Rakesh

    =C2=A0

    =C2=A0

    More notes can be found below.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    =C2=A0

    On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

    Thank you Greg for you= r further reply and the discussions.

    Good to know that y= ou do see a need for the extensions for the direct-mode packet loss detecti= on and the authors are actively working on an alternate methods using BFD (as you mentioned below).

    GIM3>> As you've recognized, in draft-mirmin-bfd-extended=C2=A0we build an integrated OAM based on the = lightweight Fault Management protocol with optional Performance Monitoring,= based on RFC 6374. RFC 6374, in turn, provides a rich set of performance m= easurement methods, including direct loss measurement.

    Please see replies inl= ine with <RG3>=E2=80=A6.

    From: Greg Mirsky <gregimirsky@gmail.c= om>
    Date: Monday, November 30, 2020 at 11:30 AM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Gyan Mishra <hayabusagsm@gmail.com>, IETF IPPM WG <ippm@ietf.org>, James Guichard &= lt;jame= s.n.guichard@futurewei.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;, Greg Mirsky <gregory.mirsky@ztetx.com>
    Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11    =

    Hi Rakesh,

    thank you for the continued discussion. I appreciate= your responses. I am still not convinced of the value these documents add.= Please find my follow-up notes in-line=C2=A0below under the GIM2>> tag.

    =C2=A0Regards,

    Greg=C2=A0

    On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

    Thank you Gyan and Gre= g for your review comments and discussions. Please see inline replies with = <RG2>=E2=80=A6

    From: Gyan Mishra <hayabusagsm@gmail.c= om>
    Date: Wednesday, November 25, 2020 at 12:34 PM
    To: Greg Mirsky <gregimirsky@gmail.com>
    Cc: IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com&g= t;, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;
    Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11    =

    =C2=A0Hi Rakesh=C2=A0

    I have been following this thread and to help progre= ss the discussion I would like to provide some comments in-line Gyan>=C2= =A0

    Thanks

    Gyan

    On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

    Hi Rakesh,

    thank you for the response to my comments.=C2=A0Plea= se find my follow-up notes in-lined below under the GIM>> tag.=C2=A0<= u>

    Regards,

    Greg

    On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

    Thank you Greg for taking time for thoroughly= reviewing the documents and providing the comments.

    Please see replies inline with <RG>=E2= =80=A6

    From: ippm <ippm-bounces@ietf.org&= gt;
    Date: Friday, November 6, 2020 at 11:18 AM
    To: James Guichard <james.n.guichard@futurewei.com>
    Cc: spring@ietf= .org <spring@ie= tf.org>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
    Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11    =

    Dear Chairs of the SPRING and IPPM WGs, Authors, et = al.,

    I've found myself in the situation when two rela= ted drafts are in the WG APs in the SPRING and IPPM WG (with the possibilit= y that expertise from the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are c= losely related, I've decided to combine my questions and comments in a = single thread. I hope that would be acceptable and considered by the SPRING= WG as well as IPPM WG.

    Usually, the bar for the adoption of a document can = be evaluated=C2=A0by answers to these three questions:

    • Is the document(s) reasonably well-written

    I've got surprised that the drafts don't use= the terminology from RFC 4656 and 5357 and introduce their own terminology= for Session-Sender and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents withou= t proper definitions. Other than that both drafts are readable and reasonab= ly well-written.

    <RG> We are ok to change Sender to Session-Sender and Reflect= or to Session-Reflector if it helps.

    =C2=A0

    GIM>> I believe that the consistency in terminology between the core = RFC and what is intended as its extension is not only helpful to a reader b= ut, to the best of my understanding, is required for IETF specifications. B= ut I don't think that switching the terminology will fix the fundamental issue with the proposal. The operation that is re= quired from the remote entity, whether it is referred to as responder or Se= ssion-Reflector, is not defined in Appendix I of RFC 5357, nor in RFCs 4656= or 5357 itself. In my opinion, the behavior required, as described in the draft, cannot be characterized = as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely n= ew protocol that, if there's a need in the new PM OAM protocol, must be= properly defined.

    =C2=A0 =C2=A0Gyan> I am in complete agreement wit= h Greg about terminology and consistency.=C2=A0 The problem with inconsiste= ncy is that that you are not following well known normative references required to understand the specification leading to confusion and misunder= standing of the specification.=C2=A0 The goal should be clear and concise i= n terminology and verbiage.

    <RG2> Agree. Wil= l address the terms from RFC 5357 in the next revision.

    <RG> There are many existing RFCs that use term =E2=80=9CLink= =E2=80=9D (e.g. RFC 5613, 5340, 8330, etc.) and term =E2=80=9CCongruent Pat= h=E2=80=9D (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we c= an add a reference for them if it helps.

    GIM>> Thank you for listing these RFCs. I thin= k I need to clarify my questions. While a reference to any of RFCs you'= ve mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

    Now I'll try to illustrate my concern with using= the term "congruent path" in these drafts (using ASCII-art):<= /u>

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0\

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A----B=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E-----F

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 /

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0G------------H

    Consider an SR tunnel from A to F that traverses the= network as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definitio= n of "congruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and siz= e as the mirror image of the other", it looks as the path A-B-G-H-E-F = is congruent to that SR tunnel. But a packet of an active OAM intended to m= onitor a flow over the SR tunnel is out-of-band relative to that flow and will not produce any meaningful measurement. Of = course, for the case of the extensions in drafts *-twamp-srpm, direct loss = measurement can be performed, as information collected from node F and pack= ets that collect the counters are not required to be in-band with the monitored flow. So, this example, in m= y opinion, illustrates two of my concerns:

    =C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 using a congruent path for active performance measurement, e.g., TWA= MP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should= reflect the fundamental requirement of ensuring that active OAM test packets are in-band with the monitored fl= ow.

    =C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 there are no technical requirements to justify using in-band test pa= ckets for direct packet loss measurement. In fact, using the in-band method= for collecting in-profile counters leads to a waste of bandwidth, which ma= y have a negative impact on services that require low-latency and/or low packet loss. As demonstrated in this e= xample, direct packet loss can be performed using an out-of-band mechanism,= e.g., SNMP queries, Netconf notifications based on YANG data model.=

    • Does the document solve a real problem?

    No, it appears that these drafts define a new perfor= mance measurement protocol for the purpose of combining OWAMP and TWAMP fun= ctionality and adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technica= l arguments for using a PM protocol instead of, for example, extending the = existing OAM mechanisms like ICMP.

    =C2=A0Gyan> =C2=A0This may sound basic but is a v= ery critical subject going down the same lines of clarity in verbiage so th= eir is no misunderstanding. =C2=A0=E2=80=9CCongruent=E2=80=9D by definition= means shape of an object and if you super imposed two objects on top of each other the= y fit perfectly and the edges coincide identically.=C2=A0 The problem with = congruent is that it is based on the shape and that shape could be a mirror= image or reflection which may not be exact.=C2=A0 So when referring to a SR-TE path taken this could lead to co= nfusion as to path taken if it=E2=80=99s the same path or congruent which i= s vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here ther= e is criticality as to the path being referenced in terms of in-band versus out-of-band.=C2=A0 I agree th= at for direct in band packet loss measurement can be done via existing OAM = mechanisme via ICMP.

    <RG2> Ok, we wil= l find an appropriate term for =E2=80=9Csending packets on the same path as= data traffic=E2=80=9D.

    <RG2> Extending = ICMP for direct-mode loss measurement is outside the scope of this draft. B= ut good to see the agreement for the direct in band packet loss measurement to be done (albeit by some other means).=

    GIM2>> I feel that you misunderstand my positi= on in regard to the use case these four documents try to solve. I don't= recall that I've stated that "direct in-band packet loss measurem= ent" requires any additional standardization work. The Direct Measurement TLV h= as solved that for STAMP and draft-ietf-ippm-stamp-option-tlv is now in the= RFC Editor's queue. I cannot find any valid technical reason to re-ope= n this and measure the direct packet loss in a slightly different way. I must point out that a claim that using= fixed positions for the direct packet loss optimizes performance does not = stand for cases (Section 4.2.1 and 4.2.2 of draft-gandhi-spring-stamp-srpm)= when the return path is specified in the Return Path TLV and, as I understand it, in some cases even the sec= ond TLV, Node Address TLV, is used. Thus, it is clear that the proposed new= method of direct packet loss measurement does not offer any significant be= nefits comparing to the STAMP's Direct Measurement TLV and appears nothing but superfluous.<= /p>

    <RG3> The direct= -mode packet loss use-case is typically for the forward direction packet lo= ss. And this does not use the return path TLV. We can clarify that in the draft.

    GIM3>> Clarification would be very helpful as = your latest note might be interpreted that the proposed mechanisms are not = applicable in the case of a bi-directional SR tunnel.

    <RG> There is a requirement to measure performance delay as w= ell as synthetic and direct-mode packet loss in segment-routing networks. O= WAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measur= ement today. I am not sure extending ICMP for LM is a good option here.

    GIM>> I agree with the=C2=A0requirements you've listed (though th= e=C2=A0SPRING WG OAM requirements document=C2=A0= has been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason=C2=A0to use OWAMP/TWAMP for exc= lusive direct packet loss measurement.=C2=A0=C2=A0

    =C2=A0 =C2=A0 Gyan> Agreed

    <RG2> There is definitely a need to = do direct-mode loss measurement in IP/SR networks, as RFC 6374 mechanisms a= re for MPLS networks. Note that there was an attempt to extend BFD for dire= ct-mode loss measurement for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03)= .

    GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense. The work and discussion of= the proposal continues and the new version will be published soon.<= u>

    <RG3> Ok, so = you do see a need for the extensions for the direct-mode packet loss detect= ion and the authors are actively working on an alternate methods using BFD. =C2=A0=C2=A0=

    • Is the proposed solution technically viable?

    There are too many unaddressed aspects, particularly= the risk introduced by the protocol on network security, to comprehensivel= y evaluate the proposed solution.

    <RG> About your = comment on zero checksum, this is described in Security section in RFC 6936= . We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

    GIM>> I don't think that a mere reference = sufficiently explains why the use of zero UDP checksum in IPv6 header is no= t decremental, does not create a security risk for the protocol.<= /u>

    =C2=A0=C2=A0 =C2=A0 Gyan> Agreed 0 UDP MIMA secur= ity threats and that you need to thorough vetting of RFC 6936.

    =C2=A0<RG2> Yes,= will add in the next revision. Hope we can work together on needed text.

    To summarize my review of=C2=A0these two drafts:<= /u>

    • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

    <RG> The probe a= nd response messages defined in [RFC 5357] are used for delay measurement a= nd synthetic packet loss. The direct-mode packet loss messages are defined in draf= t-gandhi-ippm-twamp-srpm that matc= h these delay measurement messages. As stated, draft-gandhi-ippm-tw= amp-srpm defines =E2=80=9Cextensio= ns=E2=80=9D for TWAMP Light.

    GIM>> I cannot find where RFC 5357 defines "the probe and respon= se messages". Could you give a more specific reference or provide the = text that, in your opinion, defines such messages? But I'm more concern= ed with the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to BBF's=C2=A0TR-390, = I'm have learned how different are existing implementations of TWAMP Li= ght. And that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

    =C2=A0 Gyan> I don=E2=80=99t see the probe a d re= sponse messages in TWAMP RFC 5357=C2=A0

    <RG2> Agree to u= se term test-packet from RFC 5357.

    =C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 several parts of the proposed protocol, e.g., Zero UDP checksum in I= Pv6, require detailed security analysis, which is currently absent;<= u>

    =C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

    <RG2> Please see= previous reply.

    <RG> This is spe= cified in RFC 6936 Security Section. We will add reference to this RFC in o= ur Security Section as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

    GIM>>=C2=A0 I've noted above that a simple reference does not suf= ficiently explains why the use of zero UDP checksum in IPv6 header is not d= ecremental, does not create a security risk for the protocol. I believe tha= t the proposal to use zero UDP header checksum requires extensive analysis, using the analysis provided in RFC 6936.

    =C2=A0 =C2=A0 Gyan> Completely Agree

    =C2=A0<RG2> Plea= se see previous reply.

    • I was surprised to find out that=C2=A0draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
    <RG> This was to address your previous comment qu=
oted as:
     =E2=80=9C- as I understand, the dr=
aft is applicable to TWAMP Light mode,

    =C2=A0=C2=A0 mentioned in the informational = Appendix I in RFC 5357, not the TWAMP

    =C2=A0=C2=A0 protocol itself. Since TWAMP Li= ght is not a standard but its idea is

    =C2=A0=C2=A0 described in the informational = text only, I think that the Informational

    =C2=A0 track is more appropriate for this sp= ecification.=E2=80=9D

    https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o= /

    <RG> Having said= that, we are ok to change to PS.

    GIM>> As explained in RFC 8545 "TWAMP Light is an idea", no= t a protocol. If anyone is interested in standardizing an "extension&q= uot;, I'd expect that they first define the base specification to which= the extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Could you= point to the definition, for example, of the Authenticated mode in TWAMP L= ight in the=C2=A0draft-gandhi-spring-twamp-srpm or RFC 5357?=C2=A0

    =C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

    <RG2> The Append= ix I of RFC 5357 does have information on the Authentication mode. As speci= fied there, this is based on user configured parameters.

    =C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I believe that=C2=A0draft-gandhi-spring-twamp-srpm should be anchore= d at IPPM WG as it does introduce the new PM protocol.

    <RG> The TWAMP L= ight extension draft-gandhi-ippm-tw= amp-srpm is already in IPPM WG. The SPRING draft only = defines SR PM procedures.

    =C2=A0Below, please find my detailed=C2=A0comments, = questions on these drafts:

    • draft-gandhi-spring-twamp-srpm

    I have several questions about the relationships bet= ween this draft and Appendix I in RFC 5357 where the idea of a mode known a= s TWAMP Light has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained i= n Section 4 of=C2=A0RFC 8545=C2=A0(apologies for the long quote):

    =C2=A0 =C2=A0"TWAMP Light" is an idea desc= ribed in Appendix I ("TWAMP Light
    =C2=A0 =C2=A0(Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
    =C2=A0 =C2=A0control protocol combined with the TWAMP-Test protocol.=C2=A0 = In
    =C2=A0 =C2=A0[RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
    =C2=A0 =C2=A0TWAMP Light failed to meet the requirements for IETF protocols= (there
    =C2=A0 =C2=A0are no specifications for negotiating this form of operation a= nd no
    =C2=A0 =C2=A0specifications for mandatory-to-implement security features), = as
    =C2=A0 =C2=A0described in Appendix A of this memo.=C2=A0 See also [LarsAD] = and
    =C2=A0 =C2=A0[TimDISCUSS].

    =C2=A0 =C2=A0Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br> =C2=A0 =C2=A0component of TWAMP, it is considered reasonable for future sys= tems to
    =C2=A0 =C2=A0use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
    =C2=A0 =C2=A0is specified in this document).=C2=A0 Clearly, the TWAMP Light= idea
    =C2=A0 =C2=A0envisions many components and communication capabilities beyon= d
    =C2=A0 =C2=A0TWAMP-Test (implementing the security requirements, for exampl= e);
    =C2=A0 =C2=A0otherwise, Appendix I of [RFC5357] would be one sentence long<= br> =C2=A0 =C2=A0(equating TWAMP Light with TWAMP-Test only).

    =C2=A0Since we don't have an IETF document that = addressed these open questions, I don't think we can have a draft that = proposes extensions to a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.<= u>

    =C2=A0Gyan> Agreed=C2=A0

    <RG2> The proced= ure for using the RFC 5357 defined messages in TWAMP Light configuration mo= de is defined in the corresponding spring drafts. It also describes the provisioning model.

    GIM2>> If a return path can be provisioned for= TWAMP Light, why the same method of controlling a test session cannot be u= sed for STAMP?

    <RG3> It is not = expected that all STAMP TLV extensions need to be supported for TWAMP Light= using provisioning.=C2=A0

    =C2=A0<RG> This = was to address your previous comment quoted as

     =E2=80=9C- as I understand, the dr=
aft is applicable to TWAMP Light mode,

    =C2=A0=C2=A0 mentioned in the informational = Appendix I in RFC 5357, not the TWAMP

    =C2=A0=C2=A0 protocol itself. Since TWAMP Li= ght is not a standard but its idea is

    =C2=A0=C2=A0 described in the informational = text only, I think that the Informational

    =C2=A0=C2=A0 track is more appropriate for t= his specification.=E2=80=9D

    https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o= /

    <RG> Having said= that, we are ok to change to PS as you mentioned above.

    <RG> BTW, despit= e only difference of fixed vs. variable length payload in STAMP vs. TWAMP L= ight, the STAMP is a proposed standard as RFC 8762 (and it uses the same approach of provisioning=C2=A0 as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

    GIM>> RFC 5357 mentioned TWAMP Light as an una= uthenticated, and thus the light, simpler, version of TWAMP-Test component = of TWAMP protocol. I cannot find in=C2=A0draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of TWAMP Light. Also, I'll prefer= not to refer to RFC 8762 STAMP in the discussion of "extension" = to TWAMP Light.

    <RG2> The Authen= tication information is user-configured as shown in Section 3.1 of the draf= t-gandhi-spring-twamp-srpm, and is also described in Appendix I of RFC 5357.

    Now a number of more specific questions.

    draft-gandhi-spring-twamp-srpm:

    • In the Introduction it is stated that:

    =C2=A0 The TWAMP Light [Appendix I in RFC5357] [BBF.= TR-390] provides
    =C2=A0 =C2=A0simplified mechanisms for active performance measurement in Cu= stomer
    =C2=A0 =C2=A0IP networks by provisioning UDP paths and eliminates the need = for
    =C2=A0 =C2=A0control-channel signaling.

    I can not=C2=A0find where, either Appendix I or TR-3= 90, "eliminated the need for control-channel signaling". Also, co= uld you point where the referenced documents describe "provisioning UDP paths"?

    <RG> The Appendix I of RFC 5357 has following tex=
t. We can reword and match the exact text if you prefer.
    =C2=A0
    =E2=80=9CThis example eliminates th=
e need for the TWAMP-Control protocol, and
    =C2=A0=C2=A0 assumes that the Session-Re=
flector is configured=E2=80=9D

    GIM>> I think that the text you're proposi= ng is even more confusing. It is not clear which example the sentence is re= ferring to. Also, what is the basis for such an assumption?=C2=A0=

    <RG2> This is th= e exact text from RFC 5357 Appendix I. Please go through the entire Section= in that RFC 5357 to avoid =E2=80=9Cout of context=E2=80=9D discussion.

    • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

    =C2=A0 =C2=A0The procedure uses the mechanisms defin= ed in [RFC5357]
    =C2=A0 =C2=A0(TWAMP Light) and its extensions for Performance Measurement.<= u>

    I think that the reference must be to Appendix I, no= t RFC 5357. Also, could you please specify which extensions of TWAMP Light = have been used in this draft?

    <RG> We can add the Appendix I as reference in the next revis= ion. Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add thi= s reference.

    GIM>> The problem, in my view, is that Appendi= x I of RFC 5357 must be a normative reference while it is, by its nature, a= n Informational document.=C2=A0=C2=A0

    <RG2> If approve= d, it is fine to have informational draft/RFC in a normative reference. But= RFC 5357 is PS.

    • In Section 2.3 describing the reference model is noted:
      • <= /ul>

      =C2=A0 =C2=A0The probe response message is typically= sent to the sender node R1.

      In which scenarios the reflector acts differently? H= ow such behavior is related to the behavior of a TWAMP Session-Reflector, a= s defined in RFC 5357?

      <RG> Do you prefer we remove =E2=80=9Ctypically=E2=80=9D from= the sentence?

    GIM>> If that fits into the operational model = of the new protocol you're defining.=C2=A0

    • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

    <RG> Both, pleas= e see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known term used in many= existing RFCs (please see RFC 5613, 5340, 8330).

    GIM>> Thank you for the references. I couldn&#= 39;t find a definition of an object "Link" (capitalized) but only= "link" (lower case). Hence, since the draft consistently uses th= e capitalized form, I consider it to be something else, something different from a link.= =C2=A0

    <RG2> Ok, we can= change Link to link in the next revision to avoid confusion.=

    • In Section 3 behavior of the reflector described as

    =C2=A0 =C2=A0... no PM state for delay or loss measu= rement need to be created on the
    =C2=A0 =C2=A0reflector node R5.

    That is in contradiction to the behavior of a TWAMP = Session-Reflector as defined in RFC 5357. Could you provide a reference to = an IETF standard where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way= delay and synthetic loss measurement on a bidirectional SR tunnel?<= u>

    =C2=A0Gyan> Valid point=C2=A0

    <RG2> Bidirectio= nal SR tunnel may have an SR state but the statement above is that no PM (i= .e. TWAMP Light) protocol session state is created for it. We can clarify in the next revision.

    GIM2>> So-called stateless Session-Reflector i= n TWAMP Light is only one option. I am well-familiar with the implementatio= n that uses the stateful mode.=C2=A0

    <RG3> What infor= mation stateful PM need to maintain in the state on the reflector? Doesn=E2= =80=99t that cause scale issues. We can add in the draft you if there is anything specifically needed in the spec.

    GIM3>> RFCs 5357 and 8762 are clear about what= information must be maintained by a Session-Reflector. The Session-Reflect= or must have knowledge of the test session state and count reflected test p= ackets. The value of such a counter must be copied in the Sequence Number field of the reflected packet. Thus=C2=A0= the method enables the measurement of the one-way packet loss metric.

    =C2=A0<RG> Quoti= ng the text from Appendix I in RFC 5357. We can quote the text as is.

    =E2=80=9CIn the case of TWAMP Light, the=
 Session-Reflector does not necessarily have knowledge of the session state=
. =E2=80=9C

    GIM>> By the informational nature of Appendix = I, the text is not normative. I am familiar with the implementation of TWAM= P Light which does maintain the session state and thus supports one-way packet loss measurement. If you require that the remote node does = not maintain the state, the draft must define that as part of the specifyin= g the behavior of the protocol.

    =C2=A0<RG2> Ok, = we can discuss what information is to be maintained in that state on the re= flector for synthetic packet loss. We can add appropriate text if you can help please.

    GIM2>> I don't see any reason to do that a= s that already defined in RFC 8762 and draft-ietf-ippm-stamp-yang=C2=A0

    <RG3> Ok.= =C2=A0

    =C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Further, in Section 3 the selection of UDP port explained as the fol= lowing:

    =C2=A0 =C2=A0As specified in [RFC8545], the reflecto= r
    =C2=A0 =C2=A0supports the destination UDP port 862 for delay measurement pr= obe
    =C2=A0 =C2=A0messages by default.=C2=A0 This UDP port however, is not used = for loss
    =C2=A0 =C2=A0measurement probe messages.

    To the best of my understanding, as one of the contr= ibutors and=C2=A0Editors of RFC 8545, it re-allocated UDP port 862 for use = by a TWAMP Session-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in th= e same test session, using the same flow of TWAMP-Test packets.

    =C2=A0Gyan> Agreed=C2=A0

    <RG2> Yes, we ca= n use port 862 for both delay and synthetic packet loss =E2=80=93 they are = using the same test packet. There is no change proposed in the draft.

    GIM2>> Packet delay and synthetic packet loss = measurements are already supported in RFC 8762. Are you proposing a new pro= tocol to duplicate the STAMP functionalities?

    <RG3> As mention= ed, the extensions defined are for the direct-mode packet loss measurement = for TWAMP Light and STAMP.

    <RG> The packet = loss in existing RFC 5357 refers to synthetic loss as there is no support f= or direct-mode loss in RFC 5357. We can change the text to clarify as =E2=80=9CThis UDP port however, is not used for direct-mode los= s measurement probe messages.=E2=80=9D

    GIM>> I've found that there's some mis= conception in the draft. RFC 8545 re-assigned UDP port 862 not for "de= lay measurement probe messages" but for TWAMP-Test protocol. TWAMP-Tes= t protocol, in turn, supports packet delay, packet loss, reordering (RFC 473= 7 defines packet reordering metric), and packet duplication measurement.=

    • Then the draft states that

    The sender uses the UDP port number following the gu= idelines specified in Section 6 in [RFC6335].

    Could you point to the guidelines that a user can us= e when selecting a UDP port number of a test session?

    Gyan> Good point =C2=A0

    <RG> Please see section 6 in [RFC6335]. We can cite the range= which will be the same as used in [RFC8762]. This was also discussed earli= er.

    https://mailarchive.ietf.= org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

    GIM>> I've looked through Section 6 but I = don't find anything specifically applicable to this draft we're dis= cussing. If the protocol to use UDP port numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it seems that stating that expli= citly would be the best way.=C2=A0

    <RG2> This would be, User Ports and Dynamic Ports=
 ranges, which are defined in [RFC6335=
]. Yes, we can add this text.
    • At the closing of the paragraph, we read that

    =C2=A0 The number of UDP ports with PM functionality= needs to be minimized due
    =C2=A0 =C2=A0to limited hardware resources.

    Does a UDP port number pose PM functionality? How it= is assigned to the port number?

    <RG> UDP ports a= re user configured for delay and direct-mode loss PM as described in Sectio= n 3.1.

    GIM>> Can UDP port 862 be used? Also, requirin= g that the direct-loss measurement uses port number different from the one = used by a TWAMP-Test packet, in my opinion, is another indication that this is the definition of a different from TWAMP Light PM OAM protoco= l.=C2=A0

    <RG2> If we add = a field in the packet then UDP port 862 may be used along with the new fiel= d. But it will require extra processing in hardware. It is better to use a different UDP port for processing efficiency in hardware.<= /span>

    • Following the above-quoted text, in Section 3 is noted:
      • <= /ul>

      =C2=A0 =C2=A0For Performance Measurement, probe quer= y and response messages are
      =C2=A0 =C2=A0sent as following:

      Could you clarify if the listed further procedures d= eviate from OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 53= 57 for Session-Sender and Session-Reflector respectively?

      <RG> Probe messages follow the same procedure as defined in R= FC 4656 and RFC 5357.

    GIM>> All messages, i.e., TWAMP-Test packets a= s well as the defined in=C2=A0draft-gandhi-ippm-twamp-srpm?=C2=A0=

    =C2=A0<RG2> Yes,= unless otherwise specified in the draft-gandhi-ippm-twamp-srpm.<= /u>

    • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

    =C2=A0 =C2=A0 =C2=A0 the probe messages are sent on = the
    =C2=A0 =C2=A0 =C2=A0 congruent path of the data traffic by the sender node<= u>

    It is not clear what "the congruent path" means. The definition o= f=C2=A0congruency in geometry tells us that an object B is congruent=C2=A0t= o object A if it has the same shape and size, but is allowed to flip, slide= or turn. How a path can be congruent to another path?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Agreed.=C2=A0 Th= e use of congruent in the context of pathing is confusing as the path being= addressed may not be reflected accurately by the term congruent.=

    <RG2> As replied= above.

    <RG> There are m= any existing RFCs that use term Congruent Path (e.g. RFC 5921, 6669) withou= t defining them. I suspect it is because it is well-known term. Having said that, we can add a reference for it if it helps reader.<= /span>

    GIM>> I cannot assume what was the context of = these RFCs. I've sketched a network diagram above to illustrate=C2=A0th= at a "congruent path" may well lead to out-of-band path. Is that the intention of the authors of the draft to use this protocol out-of-band= ?

    <RG2> As replied= above.

    • The last paragraph in Section 3 refers to work on iOAM:
      • <= /ul>

      =C2=A0 =C2=A0The In-Situ Operations, Administration,= and Maintenance (IOAM)
      =C2=A0 =C2=A0mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
      =C2=A0 =C2=A0SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
      =C2=A0 =C2=A0information such as timestamp in-band as part of the data pack= ets,
      =C2=A0 =C2=A0and are outside the scope of this document.

      Is iOAM in the scope of this specification? What are= the relationships between iOAM and=C2=A0draft-gandhi-spring-twamp-srpm?=

      <RG> As mentioned in the draft, IOAM is outside the scope.

    GIM>> Yes, but it appears that references to t= he two IOAM-related drafts have some purpose. What is it? How are these dra= fts related to=C2=A0draft-gandhi-spring-twamp-srpm?=C2=A0

    <RG2> We can rem= ove them if it is confusing. It is informational text (was added to address= a review comment).

    • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with=C2=A0draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?<= /u>

    <RG> Yes, this c= an be Yang model. We can review draft-ietf-ippm-twamp-yan= g and add any missing items in a s= eparate draft. We can also add a reference in this draft.

    GIM>> I think that theremust=C2=A0be some disc= ussion on how the new protocol is configured. If TWAMP YANG data model can = be augmented, I'd expect that being defined in=C2=A0draft-gandhi-ippm-t= wamp-srpm. But I couldn't find anything about the configuration of the protocol.= =C2=A0

    <RG2> The Yang m= odel extensions are not in the scope of this draft=C2=A0

    • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

    <RG> Existing TW= AMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D loss measurement.= We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clarify.=

    GIM>> True, direct loss measurement, in fact, = is not active measurement and thus is outside the scope of Two-Way Active M= easurement Protocol (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, passive measurement method and fetching= counters can be done using numerous methods, e.g., SNMP, Netconf=C2=A0<= /u>

    <RG2> RFC 7799 d= oes not say using Test-packets to collect counters for direct-mod loss meas= urement is passive.

    GIM2>> Per RFC 7799, injecting in-band test pa= ckets is the characteristic of an active measurement method. Using out-of-b= and transport, e.g., SNMP queries, would be an example of a passive measurement method.=C2=A0

    <RG3> Ok, so you= answered your own question that the direct-mode packet loss extension defi= ned is =E2=80=9Cactive measurement=E2=80=9D method.

    • Section 4.1.1 requires that

    =C2=A0 The Destination UDP port cannot be used as So= urce port, since
    =C2=A0 =C2=A0the message does not have any indication to distinguish betwee= n the
    =C2=A0 =C2=A0query and response message.

    Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Good question=C2= =A0

    <RG2> Yes, it is= unique in the domain.

    <RG> This is use= r-defined and is up to the user what UDP port to provision in a domain.

    GIM>> So, can user configure a port number fro= m the User Ports range? Or, can the same port number be used on the same sy= stem for a number of test sessions? I find the use of UDP port numbers being underspecified.

    • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test pack= et in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test pa= cket format to perform both delay and packet loss measurement.

    <RG> Ok, we can = update the text in the next revision to indicate exact name from the RFC 46= 56. We can also add text to include synthetic packet loss.=

    GIM>> I think that making it explicit would he= lp. Also, that will highlight what is being introduced by *twamp-srpm draft= s is, in fact, a new protocol to perform synthetic packet loss measurement.=C2=A0

    =C2=A0<RG2> No, = it does not change anything for synthetic packet loss.=

    • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?=

    <RG> We can upda= te the text in the next revision to indicate query format name from RFC 535= 7.

    GIM>> I cannot find any reference to a query f= ormat in RFCs 4656/5357. Could you please quote from any of these documents= ?

    =C2=A0<RG2> It i= s test-packet, we will use RFC 5357 term.

    • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
    <RG> Yes. Please see section 4.1.1 and quoted bel=
ow:
    =E2=80=9CFor symmetrical size query and =
response messages as defined in [RFC6038],=E2=80=9D

    GIM>> RFC 6038 defines an extension to RFC 535= 7 for OPTIONAL use of the symmetrical test packets. Since *-twamp-srpm prop= osals do not use TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about that either (in part because RFC 6038 came= later), I don't see that there's any certainty in what is the sze = of a test packet used in the direct-loss measurement.=C2=A0

    =C2=A0<RG2> The = test-packets as defined in these existing RFCs are used for delay and synth= etic packet loss. The direct-mode test-packets are defined in this draft.

    GIM2>> This draft defines only a new packet fo= rmat for the direct packet loss measurement. For STAMP such a mechanism is = clearly superfluous given the Direct Measurement TLV is already defined.=C2=A0

    <RG3> As replied= earlier.

    • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

    <RG> This is sam= e as TWAMP. There is no change.

    GIM>> Per RFC 5357, TWAMP uses only NTP format= . Is that the case for *-twamp-srpm?=C2=A0

    =C2=A0<RG2> No c= hange in existing in what is there in RFC 5357 and RFC 8186.<= u>

    • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

    <RG> Hardware ti= mestamps are recommended for SR use-cases. We can change the sentence.

    GIM>> Perhaps you can propose some text, that = would be helpful.=C2=A0

    =C2=A0<RG2> Ack.=

    • Section 4.1.1.1 stated that

    =C2=A0 =C2=A0A separate user-configured
    =C2=A0 =C2=A0destination UDP port is used for the delay measurement in
    =C2=A0 =C2=A0authentication mode due to the different probe message format.=

    Can that be interpreted that there could be concurre= nt authenticated and unauthenticated test sessions using this protocol? Wou= ld different authentication methods require using unique destination UDP port numbers?

    <RG> Yes, and Ye= s, and these are based on provisioning.

    GIM>> But that requirement is far outside the = TWAMP, as defined in RFC 5357.

    =C2=A0<RG2> Some= Session-Sender can use authenticated and some not. It is part of RFC 5357.=

    • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

    <RG> The direct-= mode loss defines new procedure for sender/reflector to collect traffic cou= nters, as opposed to timestamp. The rest is the same as RFC 4656 and 5357.

    GIM>> I cannot agree with your statement "= ; The rest is the same as RFC 4656 and 5357" because the sender's = direct-loss format does not have Error Estimate field, Thus, a reflected packet does not have Sender's Error Estimate, nor Error Estimate of th= e reflector. And that, in my opinion, is another clear indication that *twa= mp-srpm drafts define a new protocol, separate from OWAMP/TWAMP.<= /u>

    =C2=A0<RG2> That= field is specific to timestamps and would not apply to counters for direct= -mode loss measurement.

    • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
    • A couple of question to the following text in Section 4.1.3:<= /li>

    =C2=A0 =C2=A0The local and remote IP
    =C2=A0 =C2=A0addresses of the link are used as Source and Destination Addre= sses.
    =C2=A0 =C2=A0They can also be IPv6 link local address as probe messages are= pre-
    =C2=A0 =C2=A0routed.

      • What are the addresses of a link?

    <RG> I am assumi= ng this well-known (e.g. RFC 2328).

    GIM>> I am not familiar with the term "pr= e-routed". What does it mean?=C2=A0

    =C2=A0<RG2> Ensu= re that packets are routed over the link.

      • In which scenarios an IPv6 LLA can be used?

    <RG> I am assumi= ng this is well-known (e.g. RFC 5613).

    GIM>> So, LLA may be used as the source and de= stination addresses when testing an SR tunnel?=C2=A0

    =C2=A0<RG2> As m= entioned this is for links.

      • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such=C2=A0a=C2=A0packet will be routed, correct? That does appear as a security threat, would you agree= ?

    <RG> Absolutely = do not agree. It is no different than IP routed TWAMP packet as defined in = [RFC5357].

    GIM>> You don't agree that the processing = described cannot happen because of laws of physics or it wouldn't happe= n because no one will think of that? If the latter, I think that that is security threat.

    =C2=A0<RG2> Ther= e is no new threat like you have mentioned.

    GIM2>> Hmmm, but how the integrity of TLVs pro= posed in=C2=A0draft-gandhi-ippm-stamp-srpm can=C2=A0be protected? These are= not protected by HMAC as presented in figures 3 and 5.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    <RG3> The extens= ions do not change the processing of these existing TLVs defined for HMAC. = We can add text to indicate this.

    • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the= =C2=A0format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the tw= o is used for the delay measurement in the proposed protocol?=

    <RG> The probe q= uery packet in the Session-Sender text packet. We can update the name.

    • Section 4.2.1 states that

    =C2=A0 =C2=A0In one-way measurement mode, the probe = response message as defined in
    =C2=A0 =C2=A0Figure 6 is sent back out-of-band to the sender node ...

    Could you clarify how the responder controls that th= e response packet is sent not in-band but out-of-band?

    <RG> Please refe= r to section 3.1 in draft-gandhi-ippm-twamp-srpm.=C2=A0 This is existing be= haviour for out-of-band.

    GIM>>=C2=A0draft-gandhi-ippm-twamp-srpm does n= ot specify that it defines another new protocol OWAMP Light. And it is not = clear what you reference as "this is existing behavior". Is it to reference behavior of TWAMP test packet? But the behavior of the TWAMP-= Test protocol by itself is neither in-band, nor out-of-band. It is the enca= psulation of the TWAMP test packet that makes it either in-band or out-of-b= and.=C2=A0

    =C2=A0<RG2> Righ= t.

    GIM>> So, you believe that proposing to use th= e

    <= /div>
    --
    --000000000000d02cca05b5bc855d-- From nobody Sat Dec 5 12:39:17 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58863A0AA0; Sat, 5 Dec 2020 12:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 d8WAoHMlIoWc; Sat, 5 Dec 2020 12:39:14 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83943A07EA; Sat, 5 Dec 2020 12:39:13 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id y16so10666972ljk.1; Sat, 05 Dec 2020 12:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nwX06a76cVo1dBXDAiExtJ1QPIiZ7v95MWO0a20OkC8=; b=GZPV/04nkNlrnJqlhp08V6cqLqW1oI2ybHKTm0FZebT7IflO+KyeKaMt5T4L4g86y3 aA494hIF/ZjU5r+WnCvcjsy0RaJrt4TpIkG7QmQRRGzOrRDIr820Dnotg8F7J+m3ojgw MmqKTPM/A5HpwMrzn4jF1swupSjMi0nYDcJV5+87BBDEF6lDVkNP4gIsh3lZkHdml9zc soRiVCXQ9tm3W9j3h2SkT0aC9HqL42cY51j6wMVVORNiUSa3sAylw2hHnNqIPRBOrRQv somAnRt2D1Abfl5pA6yAkWH7a5iUb+bE5m7NF9TZ3IyhcIUpl4UtrD/4dz9fs95QlAwA RxMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nwX06a76cVo1dBXDAiExtJ1QPIiZ7v95MWO0a20OkC8=; b=HA2toaBCKzGeNWFu2NejXlhpBjWpyrEpvTCGUXDHCBLHUR8wNWLaNAl7woizi4SXeg Q8659J7xGA584CkZaVeefT/3Ts1R56y0PpJ64Iy+PW2OwhL2IfFwJ8gEZp5op66mHpj6 EEUDKjtchH0f41XgqN+g2h2H2ys0Y27ySmVAvC2Q9Lx5gnCDO1YK7iJqC2a1L7zjsNEt 9xAIuweuop48Hq4nmBNEEiocKUq2mFb+7QQpOwh45wPBiDqg6lkZZlQertA/TUfXseIa Pje4TeX2YfxTYlQoFxggkmoQAg+0OCzTpUwTYkuVb8NSSL7wCI6iJF13O3Got5u4nDg5 8Zpw== X-Gm-Message-State: AOAM5329djHELUxdHmaKXhXDBAdZ5jx+yEZ8/igWXf1FPipEbZdtcEv1 ExDx3/W4NciqsdJVOpjIZqTMUZzZfe0ODDwIGcIe69lW X-Google-Smtp-Source: ABdhPJxDUExSt/t0SfieSQpqQWqcwdT6wX+OdDrl5r4IfXwQCbbzXwaQrOFffHytl4HW1bDbWTZqRXFAcjDAI5I7cYM= X-Received: by 2002:a2e:9a88:: with SMTP id p8mr5914843lji.266.1607200751305; Sat, 05 Dec 2020 12:39:11 -0800 (PST) MIME-Version: 1.0 References: <160713850373.20757.3773225088751978175@ietfa.amsl.com> In-Reply-To: <160713850373.20757.3773225088751978175@ietfa.amsl.com> From: Greg Mirsky Date: Sat, 5 Dec 2020 12:39:01 -0800 Message-ID: To: IETF IPPM WG , IPPM Chairs Cc: draft-mirsky-ippm-hybrid-two-step@ietf.org, Greg Mirsky Content-Type: multipart/alternative; boundary="000000000000dd45fb05b5bd956e" Archived-At: Subject: [ippm] Fwd: New Version Notification for draft-mirsky-ippm-hybrid-two-step-07.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 20:39:16 -0000 --000000000000dd45fb05b5bd956e Content-Type: text/plain; charset="UTF-8" Dear All, the new version of the Hybrid Two-Step draft introduces the Authentication sub-TLV and defines its use in protecting the integrity of the data collected from each node. the Authentication sub-TLV may be added to the Telemetry Data TLV in which the node copies telemetry information as specified in the Trigger packet. The Telemetry Data TLV, in turn, collected in the HTS Follow-up packet(s). Also added is the request to allocate the HTS option from the IOAM Option-Type registry. Of course, some editorial changes. The authors believe that the draft provides a sufficiently detailed specification of the HTS protocol which is complementary to IOAM Trace Options, IOAM Direct Export, and Postcard-Based Telemetry methods of collecting the telemetry information. We would greatly appreciate the consideration of its adoption by the IPPM WG. Regards, Greg ---------- Forwarded message --------- From: Date: Fri, Dec 4, 2020 at 7:21 PM Subject: New Version Notification for draft-mirsky-ippm-hybrid-two-step-07.txt To: Haoyu Song , Wang Lingqiang < wang.lingqiang@zte.com.cn>, Greg Mirsky , Guo Zhui < guo.zhui@zte.com.cn> A new version of I-D, draft-mirsky-ippm-hybrid-two-step-07.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-ippm-hybrid-two-step Revision: 07 Title: Hybrid Two-Step Performance Measurement Method Document date: 2020-12-04 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/archive/id/draft-mirsky-ippm-hybrid-two-step-07.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/ Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-ippm-hybrid-two-step Htmlized: https://tools.ietf.org/html/draft-mirsky-ippm-hybrid-two-step-07 Diff: https://www.ietf.org/rfcdiff?url2=draft-mirsky-ippm-hybrid-two-step-07 Abstract: Development of, and advancements in, automation of network operations brought new requirements for measurement methodology. Among them is the ability to collect instant network state as the packet being processed by the networking elements along its path through the domain. This document introduces a new hybrid measurement method, referred to as hybrid two-step, as it separates the act of measuring and/or calculating the performance metric from the act of collecting and transporting network state. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000dd45fb05b5bd956e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear All,
    the new version of the Hybrid Two-Step draft= introduces the Authentication sub-TLV and defines its use in protecting th= e integrity of the data collected from each node. the Authentication sub-TL= V may be added to the Telemetry Data TLV in which the node copies telemetry= information as specified in the Trigger packet. The Telemetry Data TLV, in= turn, collected in the HTS Follow-up packet(s).
    Also added is th= e request to allocate the HTS option from the IOAM Option-Type registry.
    Of course, some editorial changes.
    The authors=C2=A0belie= ve=C2=A0that the draft provides a sufficiently detailed specification of th= e HTS protocol which is complementary=C2=A0to IOAM Trace Options, IOAM Dire= ct Export, and Postcard-Based Telemetry=C2=A0methods=C2=A0of collecting the= telemetry information. We would greatly appreciate the consideration of it= s adoption by the IPPM WG.

    Regards,
    Greg=

    --= -------- Forwarded message ---------
    From: <    internet-drafts@ietf.org>
    Date: Fri, Dec 4, 2020 at 7:21 PM
    Subject: New Version Notificatio= n for draft-mirsky-ippm-hybrid-two-step-07.txt
    To: Haoyu Song <hsong@futurewei.com>, Wang Lingqian= g <wang.lingqiang@zte.com.c= n>, Greg Mirsky <gregimi= rsky@gmail.com>, Guo Zhui <guo.zhui@zte.com.cn>



    A new version of I-D, draft-mirsky-ippm-hybrid-two-step-07.txt
    has been successfully submitted by Greg Mirsky and posted to the
    IETF repository.

    Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-ippm-hybrid-two-= step
    Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A007
    Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hybrid Two-Step Performance Measur= ement Method
    Document date:=C2=A0 2020-12-04
    Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
    Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17
    URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-mirsky-ippm-hybrid-= two-step-07.txt
    Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/=
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-ippm-hybrid-two-s= tep
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://tools.ietf.org/html/draft-mirsky-ippm-hybrid-two-step-07
    Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-ippm-hyb= rid-two-step-07

    Abstract:
    =C2=A0 =C2=A0Development of, and advancements in, automation of network ope= rations
    =C2=A0 =C2=A0brought new requirements for measurement methodology.=C2=A0 Am= ong them is
    =C2=A0 =C2=A0the ability to collect instant network state as the packet bei= ng
    =C2=A0 =C2=A0processed by the networking elements along its path through th= e
    =C2=A0 =C2=A0domain.=C2=A0 This document introduces a new hybrid measuremen= t method,
    =C2=A0 =C2=A0referred to as hybrid two-step, as it separates the act of mea= suring
    =C2=A0 =C2=A0and/or calculating the performance metric from the act of coll= ecting
    =C2=A0 =C2=A0and transporting network state.




    Please note that it may take a couple of minutes from the time of submissio= n
    until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat


    --000000000000dd45fb05b5bd956e-- From nobody Wed Dec 23 09:25:43 2020 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BAB3A0E5D; Wed, 23 Dec 2020 09:25:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <160874433799.4809.5184336256448864067@ietfa.amsl.com> Date: Wed, 23 Dec 2020 09:25:38 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-connectivity-monitoring-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 17:25:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : A Connectivity Monitoring Metric for IPPM Author : Ruediger Geib Filename : draft-ietf-ippm-connectivity-monitoring-00.txt Pages : 15 Date : 2020-12-23 Abstract: Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of measurements. Connectivity monitoring allows to supervise the state and performance of a connection or a (sub)path from one or a few central monitoring systems. This document specifies a suitable type-P connectivity monitoring metric. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-connectivity-monitoring/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-connectivity-monitoring-00 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-connectivity-monitoring-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/