Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Tue, 21 December 2021 01:11 UTC
Return-Path: <cpignata@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAFB3A0ED8 for <sfc@ietfa.amsl.com>; Mon, 20 Dec 2021 17:11:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.495
X-Spam-Level:
X-Spam-Status: No, score=-9.495 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, HTML_TAG_BALANCE_BODY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=e847wPL+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kWOH0O3O
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 TrO94i0TWUVe for <sfc@ietfa.amsl.com>; Mon, 20 Dec 2021 17:11:07 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39453A0ED3 for <sfc@ietf.org>; Mon, 20 Dec 2021 17:11:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=675921; q=dns/txt; s=iport; t=1640049066; x=1641258666; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uDTH8un8jvAV8vgw/zvHqLYkGfEsCad9UXPUDNMFsWk=; b=e847wPL+ZzH9Luf8mVczHLSBC7Q0BI5ES2zxZ41oeeYkgu535iqRm43n v0YEUxjoZVHRNqTeQFgq0UVPHzGMafwtcL/pCo0eIofOcPUG7L6NDcHCT 7Za0Zhy1z+wMM1BFstZH94KTC1xGz8EGSkFXV3Q3JP2enlPaIv9RqHHbO Q=;
IronPort-PHdr: A9a23:RI2cchWszAp+9QROf5zIsoHuSpzV8K36AWYlg6HPw5pCcaWmqpLlOkGXpfBgl0TAUoiT7fVYw/HXvKbtVS1lg96BvXkOfYYKW0oDjsMbzAAlCdSOXEv8KvOiZicmHcNEAVli+XzzMUVcFMvkIVPIpXjn5j8JERK5Pg1wdYzI
IronPort-Data: A9a23:Cbc2bq7iL9RIS5q5N9nImgxRtJjFchMFZxGqfqrLsTDasY5as4F+vjQcWjyHPffeMGSmeNpwa4nl8U0EuZbWy9diHgtkqSlgZn8b8sCt6fZ1gavT04J+FiBIJa5ex512huLocYZkHhcwmj/3auK49CMmjfnSLlbBILes1h5ZFFcMpBgJ0XqPq8Zh6mJZqYDR7zGl4LsekOWHULOR4AOYB0pPg061RLyDi9yp0N8QlgRWifmmJzYynVFNZH4UDfnZw3cV3uBp8uCGq+brlNlV/0vD9BsrT9iiiLu+LAsBQ6XZOk6FjX8+t6qK20cZ4HdtlPdgcqNBNi+7iB3R9zx14N5VtJO2QBsgFqbNg+8aFRJfFkmSOIUXpuebeiPu7Zf7I0ruNiGEL+9VJEE/LIQS5/1+DnpL3fMdITEJKBuEgoqe27ywYuhhmsplK9PkVKsRsGtnxjLfAKN6GZvCWK7No9Rf2R88g8lUFrDfatYXLz11Y3zobAdCNVYSCYgln/aAiXz2cjkeo1WQzYI16m3e10p3lrfwMdHVc8aGbctIgluCq33L/iLyBRRyHN6ayXyJ82ihjfPnnyT2XIIbEKW17Pgsi1qWrlH/ojV+uUCTu/K1jAu1XMhSbhJS8Ss1pq90/0uuJuQRliaQ+Bas1iPwkfILSYXWMD2w95c=
IronPort-HdrOrdr: A9a23:o10OS663tpur5ecbMwPXwWuBI+orL9Y04lQ7vn2ZFiY1TiXIra6TdaoguiMc0AxhJ03Jmbi7Sc69qADnhOBICOgqTPaftWzd2FdAQ7sSlrcKrweQfhEWs9QtqZuIEJIOSOEYb2IK9/oSiTPQe71LrbX3k9HLuQ6d9QYRcegAUdAH0+4NMHfiLqQAfng+OXNWLuv52uN34x6bPVgHZMWyAXcIG8LZocfQqZ7gaRkaQzY69Qinl1qTmf3HOind+i1bfyJEwL8k/2SAuRf+/L+fv/ayzQKZ/3PP7q5RhMDqxrJ4dY6xY4kuW3DRYzSTFcNcso65zXYISSaUmQ8Xeez30lMd1gJImivsly+O0EDQMkLboUcTAjfZuC+laD3Y0JbErPZQMbscuWqfGSGptnbI9esMop5jziaXsYFaAgjHmzm479/UVwtynk7xunY6l/UP5kYvHbf3+Ndq3P8iFW5uYd099RjBmc0a+ShVfbfhzecTdUnfY2HSv2FpztDpVnMvHg2eSkxHvsCOyTBZkH1w0kNdnaUk7zk93YN4T4MB6/XPM6xumr0LRsgKbbhlDONERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkfoIzfDvfIZNwIo5mZzHXl8dvWkue1j2AcnLx5FP+gClehT3Yd0s8LAX23FUgMyJeFPbC1zLdLl1qbrUnxw2OLytZ8qO
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CoBABEKcFh/51dJa3FaSdMBgEBARkDAgEGBIEchXWHCTq6c4lwkkWB9icZDw
X-IronPort-AV: E=Sophos;i="5.88,221,1635206400"; d="scan'208,217";a="960433943"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Dec 2021 01:11:02 +0000
Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 1BL1B1Lk028393 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 21 Dec 2021 01:11:02 GMT
Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 20 Dec 2021 19:11:01 -0600
Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 20 Dec 2021 20:11:00 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Mon, 20 Dec 2021 19:10:59 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QNCkQ+aTReCtBX6HVzuulN6/Ja2+M9nrcLd173IMJ+xc+oyL3YL78jV3zcpIjHtyhjkH4iGsVRsyVIzUhJn1wMOUwJ6FwLt3yP2HmTSvDn9cEtt/zf1530x0fq27I+yApKAatNiytKKoNXnIE7mQyWdYVP6p6LOGLiK+3wRRXRmCquadGSlJ87xpx3Tga7y95VxVOh1qnD87RO9UAvLlVkYjFgup5Py53jVjprK0dBygSrwL+TPDtaZBOowoAJ8h5SeMMBzh9nw6vIzhJLWlQUyKnr20o4yTpjQjjye5ZwkCvBfBnF5x3tqoALfJ8PjSPJa2wdjF8u2xquzof7tBWQ==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uDTH8un8jvAV8vgw/zvHqLYkGfEsCad9UXPUDNMFsWk=; b=lWyNQt7LJsAyLS2kg0tvS/Nz0Ci8DIvwlDDGO3dUWaBJQogJftUouOgNmOoDI1B8C50he18EjeTlOr9ycg0gdvMBb73CAesd+B2eWgwTYYzzUixHGFFWqUavw2HFLhQvzaEjaS94WcZrDIi3VFwUMqR7Be1NtEW5DWd0CKE8mHWXdiva+RHU+BtSCjQWDeXiQved8hfEE7GpX1ZLgCKQYihAzr0LyyinCW+uMApHUxFeLVdmWupCQCLEbE2g1kBGIw8D+Ih5JyGusfcbmBmzrxjtJJ7ezAanvmfYHl1UBu7u+XI0qNgl6LxYPcJ7cN4oe7EWNdi7sO+GgTW68IC4gQ==
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=uDTH8un8jvAV8vgw/zvHqLYkGfEsCad9UXPUDNMFsWk=; b=kWOH0O3O9RibVuJ2X8uGzj2jefKU5zfSv8yCW/B34XNggIhELqcN9zyXdW1jS8UkVumpziBX3oEnavNu1FWLCsoB9cxQmzd4Az42DA3Tmrp3bnOgNsS7Askv3rvYz+mWU9ahW+5MxGo61PXrg6BIEgAndvnsPpgkKKqRnqkvntM=
Received: from SJ0PR11MB5629.namprd11.prod.outlook.com (2603:10b6:a03:3ab::13) by SJ0PR11MB5598.namprd11.prod.outlook.com (2603:10b6:a03:304::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.20; Tue, 21 Dec 2021 01:10:56 +0000
Received: from SJ0PR11MB5629.namprd11.prod.outlook.com ([fe80::28a8:253b:8957:814e]) by SJ0PR11MB5629.namprd11.prod.outlook.com ([fe80::28a8:253b:8957:814e%3]) with mapi id 15.20.4801.020; Tue, 21 Dec 2021 01:10:56 +0000
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>
CC: James N Guichard <james.n.guichard@futurewei.com>, Greg Mirsky <gregimirsky@gmail.com>, "Frank Brockners (fbrockne)" <fbrockne=40cisco.com@dmarc.ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, Gyan Mishra <hayabusagsm@gmail.com>
Thread-Topic: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam
Thread-Index: AQHXz1F5VJOSQmp5JUWoFDH4F9jk5KwCudcAgAjtvoCAABcDgIAAKZkAgAAKXICAALeogIACHMmAgAFQW4CAACcHAIABERUAgAAC4wCABSLBgIAAZPeAgAAFfoCAAA1TAIAdpT2AgASQIoCAACOAgIADKDAAgAABvYCAAADlgA==
Date: Tue, 21 Dec 2021 01:10:55 +0000
Message-ID: <2C6BEA5E-D7A3-4ED7-B1AD-A9353777045D@cisco.com>
References: <4bb5abb4-a8dc-c8f0-9b99-549f683e7729@joelhalpern.com> <9DDFE3B0-54A2-47D9-B05E-A081EAEED410@cisco.com> <CABNhwV1YKvfSdbJo9LzAvGuWLvjWofHz5TuCE6Fp8SDUyxmTHw@mail.gmail.com> <B4F81D2C-1273-493E-8E90-35D32ACDE6D1@cisco.com> <DM8PR11MB560669E2E2C77AD662F6251CDA9F9@DM8PR11MB5606.namprd11.prod.outlook.com> <CA+RyBmXUBYFFgNfopErFYUgJDfJWVY59ERM0LrkEnxw_xC2MYg@mail.gmail.com> <DM8PR11MB5606B943F4D1A3B2702D53EBDA609@DM8PR11MB5606.namprd11.prod.outlook.com> <A012EBFA-FDAB-4591-8F3A-9D5882B69A57@cisco.com> <DM8PR11MB5606D7CDC99EB7FFE63095DFDA639@DM8PR11MB5606.namprd11.prod.outlook.com> <896B8A4B-3717-4150-9944-44906A593BC9@cisco.com> <CA+RyBmUaeSsjLE191jK94bGV3Nzed95tkN+mn-kCDs6WxucFRg@mail.gmail.com> <1B31F06E-974A-4BDA-8C89-81E61B8E6868@cisco.com> <CA+RyBmUax4VmKpMvW-JErrdjZj09kV2fCofiKH91E0qYRhGatA@mail.gmail.com> <CE085BD4-1DD3-484E-B94C-6800C9F38CFA@cisco.com> <005e334c-fd02-e7b2-4bef-3d0551c1b289@joelhalpern.com> <FE19CCFA-D499-4C3E-AB52-0E1F771D5371@cisco.com> <07cd39c5-9078-ec76-b340-43665d8805eb@joelhalpern.com>
In-Reply-To: <07cd39c5-9078-ec76-b340-43665d8805eb@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3693.40.0.1.81)
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 308b491f-dbab-4d27-e0d2-08d9c41ebdc5
x-ms-traffictypediagnostic: SJ0PR11MB5598:EE_
x-microsoft-antispam-prvs: <SJ0PR11MB5598FC8760DB97716E0C5EA9C77C9@SJ0PR11MB5598.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5516;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bNVgn4uyoshh7U5nbJFmqcsqQ5ID6zsYmD3CnAI3Mjf/drtsTj6DlZ55RKfTYUKWUiESlfRaIXlBKRpcv6c7OOgMNUcUabP3dfnoXLbchNwoaJeFRkWLg7mhvrc91QzvPBv9hJPQWTG2mH3dIaKkLgK6KkeGBBuXfV4op0BcZg95outYtx2JnAI3fDHYAH6ZOxenjejn2krw8EYEPh+qbl6k2fddIZIH9RL2oGxf2ZI4V4wnN74nGwF4H6PE1Dw3+AqgtAgC09zktLGHIkl/BhuZpu/+Q1lheEysGrAgshCUqdKQzdlnRnnbIZIN0tWESMqdR+qZn/3BB8AtX8Zax2LeUkRO966bjawHz323V51vVAiHRfvExnCQlbwYI+dSOSdYzX7RWPiGgeQqp09O4WvqKljMfl9iXp8kEwNdwhsB4COUrAlVlEf1eRlIOIUstdCh4CRcBboTqwA3LjCbKLSTZnlnD3vfWEp4Pv9rV0bL3JKkuWvhMN79nSYW6SflBjV5nln6kQEsLhm/TLwJgOJlQ6feeszLABf69A/xqBSQdEykZ9wxMY97czaLGp9uuuNyilpU4rT7CTUmo1TxEkenDy85yPs0IUhXmnCJLyhkvwVGYqvZSix6VjxSNpFdKeeOl+bKnPTaDZVUceHtMGO1f7MghnCSjP9tNq/APl5crxo9q4UQzGlIjCJwLrgDEv/7yzgVgV+Qp4b56p+oo+wh+Wtv2PVYiA4YZJfCGPHX5BoUjT9abSrcDG2+WZL3uJm/uMDLFnOL+vR5MsPDEMWRmKAXD9Rq3ugFO2zoBsEnWBeEwXzzWje8XBIcfRzj7uTLOk4f46QGJSH84KrD0SqqpjK8OMnP3LzH7wpdXZVIuoK2AUu5IY0+7d7b0Gtm
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB5629.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(54906003)(40140700001)(38070700005)(86362001)(8676002)(66446008)(6916009)(966005)(508600001)(83380400001)(122000001)(8936002)(166002)(316002)(2906002)(36756003)(66946007)(6486002)(66476007)(5660300002)(30864003)(76116006)(91956017)(33656002)(26005)(2616005)(6506007)(66556008)(53546011)(71200400001)(38100700002)(64756008)(6512007)(186003)(4326008)(69594002)(45980500001)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: veZyaf/92QX1TTtkudvw0Gz/HYY2ROv/TWC16dWDHm0S0D9zFEug9/0NgXwoE8cWBHVilO47IAE+uwRW3dVWO3e0Gpqz/DhLdBOCVxaMdCwvZAr0LDSNco3CsL53qXXL21eJfqolCrLKXWpd4y8yim5ED2HtnsVMpxwvyOCgHuCMkqJbXqp2Ggb8bRc9YINRdX4M4g1Of+CAA+s3IARfWlk8Bfzr/9ttZRETIC3tTJpkgFIp3lDC/kyE4cjfyml0rGRojhKlxj6DHdkKedYXsNL9eAgW6J5HYzWU7uw2upuyWlhaGvP7BPI+qW35B/E39XmrqgVpZ7Jk22kb2WOyMAQx2NC36GS9cniz7CIAGnr7w1t8ataOn6pgBZB+1wmX4cUeUrbrZeXmKo/dk/Q6ovD4na7cgJsDioNpFzA1qRWux63bWbZDIQ9VKnZVOBW+JgjCWGv1kO0yFvG+QXmeSuzBgiuA6kgSi9/CLdHoe0LRj5ZS858NeCXo+WU3cfoTb9AqUXoIHW13a5fXM09F2Ei3c9qG1DtghOlff2IbcIlZRWQ4sYQDXLRS3JKT9F1uNl9SZ97I9myLVPQszlZr/NK3U0taIX91aWf267itOD8zSXEfNEbq7QYbysQLK8K7DtL4h7lyW8/1KSjaBdjC6Y9u+a8Xw34UxoKtypu4LepkhWPfrCYAsBeHf9FAwofYRYXo0HbqrOn2guRocNFS9eQA5upd33bG634WbUXR9XmJ8gWoU/broYUwc/DCOtGdD4j/xOBwFkCe10jyOm8UJgCyA3B3CmM0RoW/GrVVvGfO+u/0ZOnacdbQYuSIwpN4I8h0C3bKILh2rfM7UfMoQScCosY9qviF7hM8uvDeYt3NMVPqJF+Vh13LjkdHRBm8RhAW8/l+nOdp+/TQesTwwgjMcq6S6GwMK9oyO/acgnUOiRZC+7DsNichZZaF3Qo2iZRP6WB4nSnSNXWkxLioFlhPfVfIVq+gWg0nqMM5klnjncpATtt2zDxIkeLkaAZzOzbmAb5q4AQkSHm/MDOqRRhm+f947j9amluNlrCLXSBXnq32ebSZqtL8dQYMvkj2esCdGNjoDdhg092m/69B5hCe+qB+1ocXDq9AlZB6b+45lALDFPUR1rzU62hEa6ZQh/ZjMo9d80/es2RlseSFpJ43PJnlyAppufCDcuzVeB/nq5QPETLQ7pK9in4BLUsBhKPVP7BMQZqTCUT7NHUdrqwpqJznFs4zlxrKh+aC4rirfkBuFMFqT7ct/ByFgxahcyyl/EvqKl59EouLuuHsdVBZNxwOjEzZ4BNV8H0V+/h92TM5Q1Sed3SBWPXRkWRSEg9MpFMk13Lz3GgDcbPiv6PE0kaMtBBHJbQxqa2A+gikGmbHSOyyWscnFZffSbsR0BzS0Tu/CO7sR2Ow6aOZrk23YMNpKOqg2Le8ksSj0W8O8J7RcfqRV9E/baFJfMkn6b9rL2bZAL6JIck8rbwutz3syxHiK61Pz7PmxskixkHIx1U9HI7AV6soAoY3hF8+lwltM80lzSipLn2PMP3wdnK+RyfVUb7mz28/MP1MTINkVukPeaS0VtWptZMFfG5XZaX46bQeTlBYimlAowOmrks/0oFjWM/ELKnxlj161pRUVODnre928aDSKfQ9+nWd
Content-Type: multipart/alternative; boundary="_000_2C6BEA5ED7A34ED7B1ADA9353777045Dciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5629.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 308b491f-dbab-4d27-e0d2-08d9c41ebdc5
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2021 01:10:56.0311 (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: JISqWGm96VyWLpnxA0UkO0GJoLbjEsZL0ZvA12+tvOrfxxkipMwBIAGKjMz1Ws+zYaQRrvZrKIoDz3/UWcTICQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5598
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/pNpj7Haa7du_IikVTig7ChCD3Sc>
Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Dec 2021 01:11:17 -0000
For this usage https://datatracker.ietf.org/doc/html/rfc8924#section-7.1, the O-bit should be set. For any “vanilla” ICMP in traffic is not. On Dec 20, 2021, at 8:07 PM, Joel Halpern Direct <jmh.direct@joelhalpern.com<mailto:jmh.direct@joelhalpern.com>> wrote: from what I read, the example you provided was of an underlying ICMP Echo packet. As I understood your email, you want SFC to mark that as OAM in the NSH header. I would not have expected that behavior from the existing texts. As such, whichever way we want it to work, we would seem to need to clarify our collective expectation. More generally, I assumed the O bit of the SFC NSH header was concerned with OAM related to SFC. I think, although I could be wrong, that you read it more generally. Again, if different folks read it differently, we benefit from clarity. Yours, Joel On 12/20/2021 8:01 PM, Carlos Pignataro (cpignata) wrote: Hi Joel, Sorry if I was not clear — I did not mean infer from a packet payload the function type. I meant: look at the O-bit. If set, it is OAM. The NP says how that OAM is encapsulated, which can include IP->ICMP. Based on that, what part of the definition you feel is unclear? From RFC 8300: O bit: Setting this bit indicates an OAM packet (see [RFC6291]). … The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM packets. The O bit MUST NOT be modified along the SFP. This seems to match what I understand is also your preference. What exactly is needed to be updated on the definition of the O-bit? Best, Carlos. On Dec 18, 2021, at 7:48 PM, Joel Halpern Direct <jmh.direct@joelhalpern.com<mailto:jmh.direct@joelhalpern.com>> wrote: Just commenting on one aspect of your note. I think the definition of the SFC NSH header O bit is unclear. It never occurred to me that one would expect an SFC classifier to not that an inncoming packet was carrying ICMP, look at the ICMP type, decide it was an OAM packet, and set the O bit in the SFC NSH header. No, nothing in the OAM framework prohibits that. But nothing leads one to expect it either. Thus, I think it is helpful to clarify the meaning of the O-bit. Personally, I rather like saying that the NSH O bit is to indicate the presence of OAM for SFFs. But my personal view is largely irrelevant. It would be good to hear from others in the working group. Yours, Joel On 12/18/2021 5:41 PM, Carlos Pignataro (cpignata) wrote: Dear Greg, Thank you for the reply — please find inline my follow-ups (to the comments you responded to, even though there’s a few you missed or otherwise skipped) As dialogue in this thread seem to be getting intertwined and hard to follow, with several weeks between responses, I will let the chairs (I believe there’s no shepherd assigned) track the issues and review comments (not sure if there’s an issue tracker)and take it from here. Happy Holidays! 12/15/21 午後8:00、Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com>>のメール: Dear Carlos, please find my notes below in-line under the GIM2>> tag. Attached is the diff highlighting two editorial changes. Regards, Greg On Fri, Nov 26, 2021 at 8:18 PM Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com> <mailto:cpignata@cisco.com>> wrote: Dear Greg, I disagree. My perspective is that they go from not helpful to plain harmful. Let’s look at those three aspects one-by-one (changing the bulleted list into a numbered list for ease of tracking): 1. This is no different than RFC 8300. The O bit specifies the packet being OAM, GIM2>> I don't know of a definition of an "OAM packet". Even more, RFC 8300 does not refer to any such definition, nor does it provide it. draft-ietf-sfc-multi-layer-oam clarifies the use of O bit for the active SFC NSH OAM. CMP2: I am not sure of the implication of you not knowing that definition, nor do I see this response moving alignment forward. CMP2:From RFC8300: CMP2: The O bit MUST be set for OAM packets and MUST NOT be set for CMP2: non-OAM packets. The O bit MUST NOT be modified along the SFP. CMP2: And RFC8924 includes “OAM packet” 30 times. 1. the Next Protocol specifies the type of packet which can be “Active SFC OAM” * Stating however that the identification is based on a combination of fields is incorrect. 2. This is not a generic behavior that needs specifying or updating. It is part of the specific NSH Next Protocol value behavior for the NSH Next Protocol being defined as “Active SFC OAM”. 3. This is incorrect and a serious over-reach. Specifically: * If the O bit is set and the Next protocol is not “Active SFC OAM”, the definition is much beyond the scope of this document — since this document specifies behaviors for one specific SFC OAM protocol which is “One Active SFC OAM” (name to be narrowscoped as per other pending thread) GIM2>> I don't see why you re-name the Active SFC OAM protocol into "One Active SFC OAM". That is not what is in the draft. Are you preparing another draft that you believe will update draft-ietf-sfc-multi-layer-oam by introducing an additional active SFC OAM protocol? CMP2: My point is that draft-ietf-sfc-multi-layer-oam is not the only Active SFC OAM protocol. CMP2: RFC8924 includes ICMP, which by simply setting O=1 and NP as IP can be used. * If the O bit is set and the Next protocol is not “Active SFC OAM”, and this document somehow concludes that the OAM is in the Context Header, then it is: o Breaking other OAM protocols including other Active SFC OAM protocols encapsulated in IPv4, in IPv6, SFC Trace. It is valid to have O=1, NSH NP as IPv4, and an OAM packet encapsulated. GIM2>> Protocols that use IP/UDP encapsulation are not active SFM OAM protocols even though they might be used as such. I expect that if the payload of NSH is an ICMPv6 echo request, the O bit will be cleared and the Next Protocol set to IPv6 value. CMP2: The first sentence is interesting: CMP2: 1. please point to a reference that explains that using a specific encapsulation prevents specific functionality. CMP2: 2. What is a protocol used as active OAM but not being active OAM? CMP2: Regarding the second sentence, thanks for sharing what you expect — however that is different than what specs write :-) Why would encapsulation dictate the value of the O bit? Take for example BFD encapsulated in IP… o Breaking the use of context headers, since they need context that ought to equally apply to OAMs and to data packets, as for example a Flow Label, a Forwarding context, etc. Re-writing Context Headers breaks that. GIM2>> draft-ietf-sfc-multi-layer-oam does not include any processing that requires re-writing an NSH Context Header. CMP2: Your document says the following: CMP2: - An SFC NSH Context Header(s) contain an OAM processing CMP2: instructions or data. CMP2: which prevents using context header for spec’ed context header uses. I’d encourage the WG, shepherd, and WG Chairs to more closely inspect and review this document, specifically whether is defining one SFC Active OAM protocol, or breaking functionality while redefining base RFC 8300 behavior. Although these were brought up before, highlighting a couple of comments: 1. Introduction Also, this document updates Section 2.2 of [RFC8300] in part of the definition of O bit in the NSH. CMP: I do not see the need to redefine the O bit in the NSH. 4. Active OAM Identification in the NSH The O bit in the NSH is defined in [RFC8300] as follows: O bit: Setting this bit indicates an OAM packet. This document updates that definition as follows: O bit: Setting this bit indicates an OAM command and/or data in the NSH Context Header or packet payload. CMP: There is, as shown above, no need for this. GIM2>> As a result of RFC 8300 not providing a reference or definition of an "OAM packet", this draft addresses that for the case of Active SFC OAM. CMP2: Thank you for explaining the rational for the O-bit text in your document. CMP2: Please search for “OAM packet” in existing RFCs going back to at least 15 years ago. CMP2: draft-ietf-sfc-multi-layer-oam does not provide the definition (not needed frankly) of what you say needs defining. * O bit set and the "Next Protocol" value does not match the value Active SFC OAM (TBA1), defined in Section 9.1: - An SFC NSH Context Header(s) contain an OAM processing instructions or data. CMP: As shown above, this 1. breaks functionality (e.g., Flow Label in context) and 2. has absolutely *no* need to be included in this specific OAM protocol document. GIM2>> If there's no NSH Context Header with OAM processing instruction or data, then the O bit will not be set. If one or more NSH Context Header includes OAM processing instructions or data, then, I assume, the O bit will be set. draft-ietf-sfc-multi-layer-oam does not change that. (I much appreciate Frank's comments and the discussion that helped clarify that scenario.) CMP2: Can you please share a reference to OAM in NSH context headers? 5. Active SFC OAM Header This document defines Active OAM Header (Figure 2) to demultiplex active OAM protocols on an SFC. CMP: The identification of OAM protocols is already solved directly in RFC 8300 by using the NSH Next Protocol. CMP: This meta-header is redundant at best. Msg Type - six bits long field identifies OAM protocol, e.g., Echo Request/Reply or Bidirectional Forwarding Detection. CMP: First, why would BFD be carried as “One SFC Active OAM protocol” -> G-ACh-like meta-header with BFD Msg Type? GIM2>> draft-ietf-sfc-multi-layer-oam does not define how BFD to be carried in NSH environment. Will remove the reference to BFD in the next update. CMP2: Whether you remove it from your draft, it is still another SFC Active OAM Protocol. CMP: Second, I believe this also explains that what this document is defining is the “Echo Request/Reply” Active OAM Protocol. CMP: Since the name of the active OAM protocol defined in this document is "Echo Request/Reply”, could I please request to: CMP: 1. Provide a more specific name (since Echo Request/Reply can easily be confused with using ICMP) GIM2>> Throughout the document, "Echo Request/Reply" and "SFC Echo Request/Reply" are used interchangeably. Will add an explicit note to that in the Terminology section. CMP2: Whether there’s a global replace, ICMP can still be another SFC Active OAM Protocol. CMP: 2. Rename the title of this document to clearly define its scope for one specific SFC Active OAM protocol, by name, and not all Active OAM Protocols? GIM2>> The document provides the framework for Active SFC OAM and defines SFC Echo Request/Reply protocol. I will gladly update the title of the document, the WG decides that is necessary. CMP2: What you write immediately above does not match the Abstract of draft-ietf-sfc-multi-layer-oam. CMP2: And again, the only time the word “Framework appears in this draft is as part of the Citation for RFC8924! :-) CMP2: No other framework needed. CMP2: The Abstract says “requirements”, "an encapsulation”, "a mechanism to detect and localize defects”… you say now a “framework” and “a protocol”. Best, Carlos. Best, Carlos. On Nov 26, 2021, at 10:30 PM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com>> wrote: Dear Carlos, I believe that the proposed new text clarifies several aspects of O bit: * active SFC NSH OAM packet is identified by the combination of O bit set and the value of the NSH' Next Protocol field is Active SFC OAM; * the combination of O bit clear and the Next Protocol set to the Active SFC OAM value - erroneous and must be reported; * O bit set and the Next Protocol is not Active SFC OAM - Context Header(s) include OAM processing instructions or data. Would you agree that these are helpful clarifications? Regards, Greg On Fri, Nov 26, 2021 at 7:10 PM Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com> <mailto:cpignata@cisco.com>> wrote: Thank you Frank and Greg — what is the actual behavioral change in the proposed redefinition of the O-bit from the processing and rules defined in RFC8300? Thanks, Carlos. On Nov 26, 2021, at 4:09 PM, Frank Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org<mailto:fbrockne=40cisco.com@dmarc.ietf.org> <mailto:fbrockne=40cisco.com@dmarc.ietf.org>> wrote: Hi Carlos,____ __ __ Personally I don’t see a strong need to evolve the definition of the O-bit – but if the working group decides to do so, IMHO it would be good to ensure that the O-bit indeed signals the fact that active OAM information related to NSH is carried.____ __ __ Cheers, Frank____ __ __ *From:*Carlos Pignataro (cpignata) <cpignata=40cisco.com@dmarc.ietf.org<mailto:cpignata=40cisco.com@dmarc.ietf.org> <mailto:cpignata=40cisco.com@dmarc.ietf.org>> *Sent:*Tuesday, 23 November 2021 15:44 *To:*Frank Brockners (fbrockne) <fbrockne@cisco.com<mailto:fbrockne@cisco.com> <mailto:fbrockne@cisco.com>> *Cc:*Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com>>; Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com> <mailto:hayabusagsm@gmail.com>>; James N Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com> <mailto:james.n.guichard@futurewei.com>>;sfc@ietf.org<mailto:sfc@ietf.org> <mailto:sfc@ietf.org>; Joel Halpern Direct <jmh.direct@joelhalpern.com<mailto:jmh.direct@joelhalpern.com> <mailto:jmh.direct@joelhalpern.com>> *Subject:*Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam____ __ __ Frank, Greg,____ __ __ Do you see a reason to redefine the O-bit?____ __ __ Thanks,____ __ __ Carlos.____ ____ 11/23/21午前9:33、Frank Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org<mailto:fbrockne=40cisco.com@dmarc.ietf.org> <mailto:fbrockne=40cisco.com@dmarc.ietf.org>>のメール:____ __ __ Hi Greg,____ ____ Thanks for the quick reply. Please see inline.____ ____ *From:*Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com>> *Sent:*Monday, 22 November 2021 23:16 *To:*Frank Brockners (fbrockne) <fbrockne@cisco.com<mailto:fbrockne@cisco.com> <mailto:fbrockne@cisco.com>> *Cc:*Carlos Pignataro (cpignata) <cpignata=40cisco.com@dmarc.ietf.org<mailto:cpignata=40cisco.com@dmarc.ietf.org> <mailto:cpignata=40cisco.com@dmarc.ietf.org>>; Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com> <mailto:hayabusagsm@gmail.com>>; James N Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com> <mailto:james.n.guichard@futurewei.com>>;sfc@ietf.org<mailto:sfc@ietf.org> <mailto:sfc@ietf.org>; Joel Halpern Direct <jmh.direct@joelhalpern.com<mailto:jmh.direct@joelhalpern.com> <mailto:jmh.direct@joelhalpern.com>> *Subject:*Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam____ ____ Hi Frank,____ thank you for your comment describing an interesting IOAM use case in SFC NSH. I've thought about this case and I have several questions. I greatly appreciate your help clarifying them to me:____ * Is it envisioned that the IOAM can be part of NSH payload but not to immediately follow the SFC NSH? Perhaps such a case can be referred to as "IOAM inside NSH payload" to differentiate from "IOAM on top of NSH payload"? For example, assuming that the client payload is IPv6, then NSH is followed by an IPv6 packet, which, in turn, is followed by IOAM. ____ * If IOAM inside NSH payload is a viable use case, which SFC element is the intended addressee - SFF or SF/SF Proxy? If it is the former, what are the requirements for an SFF to handle this scenario? If it is the latter, what happens with the client packet if an SF/SF Proxy does not support IOAM in NSH but only NSH per RFC 8300?____ …FB: The scenario that you outline, i.e. NSH over “IPv6 with IOAM encapsulation”, sounds valid to me; and it could even be that NSH would also leverage IOAM, in which case, it would become a case of “IOAM Layering” as described inhttps://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2 <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2>. As outlined in the draft-ietf-ippm-ioam-deployment, IOAM-Data-Fields are specific to the layer (and the associated protocol) that they’re encapsulated into. As such, in the case of NSH over “IPv6 with IOAM encapsulation” it would be the IPv6 forwarder that would handle the IOAM processing. SFF/SF would be orthogonal/ships-in-the night.____ I've looked through draft-ietf-sfc-ioam-nsh but I couldn't find answers to these questions (I admit, I could have missed it).____ Also, I think that your suggestion to avoid any reference to a hybrid OAM protocol concentrating on the active OAM identification in the update to O-bit definition is logical and reasonable. Below, please find the proposed update:____ OLD TEXT:____ * O bit set and the "Next Protocol" value does not match one of____ identifying active or hybrid OAM protocols (per classification____ defined in [RFC7799]), e.g., defined in Section 9.1 Active SFC OAM____ (TBA1).____ ____ - a Fixed-Length Context Header or Variable-Length Context____ Header(s) contain an OAM command or data.____ ____ - the "Next Protocol" field determines the type of payload.____ ____ * O bit set and the "Next Protocol" value matches one of identifying____ active or hybrid OAM protocols:____ ____ - the payload that immediately follows the NSH MUST contain an____ OAM command or data.____ ____ * O bit is clear:____ ____ - no OAM in a Fixed-Length Context Header or Variable-Length____ Context Header(s).____ ____ - the payload determined by the "Next Protocol" field MUST be____ present.____ ____ * O bit is clear, and the "Next Protocol" field identifies active or____ hybrid OAM protocol MUST be identified and reported as an____ erroneous combination. An implementation MAY have control to____ enable processing of the OAM payload.____ ____ NEW TEXT:____ ____ …FB: The new text looks better. Couple of additional thoughts inline below.____ ____ * O bit set and the "Next Protocol" value does not match defined in____ Section 9.1 Active SFC OAM (TBA1).____ ____ …FB: The above sentence doesn’t sound complete. Likely you wanted to say something like “O bit set and the "Next Protocol" value does not matchany of the SFC Next Protocol values definedefined in Section 9.1 Active SFC OAM (TBA1).”____ ____ ____ - a Fixed-Length Context Header or Variable-Length Context____ Header(s) contain an OAM command or data.____ ____ …FB: Given that it applies to both, fixed and variable – how about simplifying to “Context-header(s) that contain active OAM commands and/or data.”____ ____ - the "Next Protocol" field determines the type of payload.____ ____ * O bit set and the "Next Protocol" value matches Active SFC OAM____ (TBA1) value:____ ____ - the payload that immediately follows the NSH MUST be the____ Active OAM Header (Section 5).____ ____ * O bit is clear:____ ____ - no OAM in a Fixed-Length Context Header or Variable-Length____ Context Header(s).____ …FB: Similar to the note above, “No Context-header(s) that contain active OAM commands and/or data.” might be simpler____ ____ - the payload determined by the "Next Protocol" field MUST be____ present.____ ____ …FB: Isn’t this obvious? The reader might wonder why this is even stated. IMHO we could safely remove this bullet.____ ____ * O bit is clear, and the "Next Protocol" field is set to Active SFC____ OAM (TBA1) MUST be identified and reported as an erroneous____ combination. An implementation MAY have control to enable____ processing of the OAM payload.____ ____ …FB: Just cosmetic, but it would be good to stay with the pattern of “condition: action” of this paragraph, e.g.____ ____ * O but is clear andthe "Next Protocol" field is set to Active SFC____ OAM (TBA1):____ ____ - Erroneous combination. The combination MUST be identified and reported. ____ In addition, what would be good, is to expand a bit on how that reporting is supposed to happen – as well as what is supposed to happen with the packet that contains the erroneous combination. Is it going to be forwarded or dropped? Is the node detecting the error supposed to remove the active IOAM header, etc., …?____ ____ Thanks again, Frank____ ____ ____ I hope that the proposed update addresses your concern.____ ____ Regards,____ Greg____ ____ On Mon, Nov 22, 2021 at 11:56 AM Frank Brockners (fbrockne) <fbrockne@cisco.com<mailto:fbrockne@cisco.com> <mailto:fbrockne@cisco.com>> wrote:____ ____ Just saw this thread – and the section on the O-bit in section 4 caught might attention.____ ____ * O bit is clear, and the "Next Protocol" field identifies active or____ hybrid OAM protocol MUST be identified and reported as an____ erroneous combination. An implementation MAY have control to____ enable processing of the OAM payload.____ Per what is mentioned below, the statement contradicts the principles of IOAM operation. A packet with O-bit cleared can very well have a hybrid OAM protocol in the next protocol field. IOAM is classified as a “Hybrid Type I” protocol per RFC 7799. A key objective of IOAM is to trace packets through the network as if they weren’t observed, i.e., the packet forwarding operation of a packet with IOAM is expected to be that of a plain packet, i.e., a packet without IOAM. Consequently, draft-ietf-sfc-ioam-nsh states clearly that the O-bit isn’t changed when IOAM is added to an NSH-tagged packet:https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2 <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2>____ ____ I’d strongly suggest to re-word section 4 to either avoid the reference to “hybrid IOAM” entirely, or to explicitly list which hybrid OAM approaches the section applies to – and that way ensure, that IOAM is not affected. An even simpler approach would be – as discussed below – so simply avoid the redefinition of the O-Bit.____ ____ Thanks, Frank____ ____ ____ *From:*sfc <sfc-bounces@ietf.org<mailto:sfc-bounces@ietf.org> <mailto:sfc-bounces@ietf.org>>*On Behalf Of*Carlos Pignataro (cpignata) *Sent:*Monday, 22 November 2021 00:52 *To:*Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com> <mailto:hayabusagsm@gmail.com>> *Cc:*James N Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com> <mailto:james.n.guichard@futurewei.com>>; Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com>>;sfc@ietf.org<mailto:sfc@ietf.org> <mailto:sfc@ietf.org>; Joel Halpern Direct <jmh.direct@joelhalpern.com<mailto:jmh.direct@joelhalpern.com> <mailto:jmh.direct@joelhalpern.com>> *Subject:*Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam____ ____ Hi, Gyan,____ ____ Thank you for your response!____ ____ On #1, I recall LIME (I co-chaired), but there’s no “LIME” reference in draft-ietf-sfc-multi-layer-oam, not I see the relationship. The draft you quote on https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02 <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02> seems to have expired many years ago. ____ ____ Further, Greg Mirsky wrote that it was for “Historical” reasons. Which one is it?____ ____ On #2, thanks for suggesting that section to be added. I agree.____ ____ On #3, thanks for the description of the various sections of draft-ietf-sfc-multi-layer-oam.____ ____ For the record I still do not see how foundational changes like the O-bit redefinition are needed.____ While you write that "trace an SFP” is a new functionality, there’s open source running code I-D documented tools which do that.____ ____ Best,____ ____ Carlos.____ ____ ____ 11/20/21午前10:36、Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com> <mailto:hayabusagsm@gmail.com>>のメール:____ ____ Hi Carlos____ ____ Many Thanks for your feedback____ ____ Responses in-line____ ____ On Fri, Nov 19, 2021 at 11:39 PM Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com> <mailto:cpignata@cisco.com>> wrote:____ Dear Gyan,____ ____ I hope all is well!____ ____ Could I please ask three short clarifying questions, follow-ons on your statement below?____ ____ 1. When you write "/with an Active Multi layer OAM model/”, can you please explain what exactly is “Multi layer” about this “OAM model”, and why is important? You highlight it in your top-post but I cannot find that text in the draft.____ ____ When I asked your co-author Greg Mirsky, he said:____ Additionally, I wonder: Why the file name “sfc-multi-layer-oam”?____ GIM>> It is historical. ____ OAM has historic connotations but for good technical reasons as called multi layer as it provides a different job of managing different layers of the network thus the nomenclature “multi layer”____ ____ We can add some verbiage to the draft as we have the draft and file name with “multi layer” in the name.____ ____ LIME is a concluded WG on OAM that has discuss the OAM management of the various layers of the network.____ ____ https://datatracker.ietf.org/wg/lime/about/ <https://datatracker.ietf.org/wg/lime/about/>____ ____ OPSWG has this draft which hones in on the multi layer OAM aspects of PM and Fault management of SFC. ____ https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02 <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02>____ ____ This draft talks about a transport independent OAM where OAM mechanisms are data plane transport dependent thus the concept of multi layer OAM requirements of multiple discrete layers of OAM to map to each layer of the network. This document also talks about E2E OAM inter layer OAM considerations in SFC as the fault may occur with the service functions at different OSI layers being chained and different network layers.____ ____ ____ ____ 2. When you write "/fills a crucial gap for operators/”, are you aware of interoperable implementations (which I expect is what operators need for it to be useful in an actual deployment)? Perhaps an RFC 7942 "Implementation Status” section could be added?____ ____ Gyan> I am not aware of any implementations however Ican review with the authors on adding the section. Thank you____ ____ ____ 3. When you write “/for new OAM functionality/”, could you please clearly describe or explicitly enumerate the specific *new* functionality you refer to, on top of what existing OAMs provide, and how you find that crucial, specifically?____ ____ Troubleshooting SFC is a complex tax for operators and having additional OAM capabilities that can provide value to operators in E2E SFC troubleshooting is a major gain for operators.____ ____ RFC 8924 defines the base specification for SFC OAM, requirements analysis and generically existing OAM mechanisms used at various layers and how they can apply to SFC defined in section 7. ____ ____ This draft provides a comprehensive SFC OAM solution and takes the base SFC OAM RFC 8924 and existing network layer mechanisms and applies them to SFC OAM localized SFC fault isolation with a new Active OAM header, Authenticated Echo Request/Reply message and Source TLV. ____ ____ The new functionality in this draft is defining a new procedure for Active OAM message on RSP in NSH updating NSH RFC 8300 definition of the O bit which indicates an OAM command and/or data in NSH header or packet payload discussed in section 4. ____ ____ Section 5 talks about the issue related to additional IP/UDP headers in an IPv6 network adds noticeable overhead and this draft defines a new active OAM header to demultiplex Active OAM protocols on an SFC.____ ____ Section 6 defines a new Active OAM based Authenticated Echo Request/Reply message for SFC that addresses additional requirements, fate sharing, monitoring of continuity between SFPs, RDI by ingress to egress, connectivity verification, fault localization and tracing to discover RSP and finally on-demand FM with response back to initiator. ____ ____ This draft also provides OAM integrity check with authentication of request/reply message in conjunction with use of source TLV to prevent DDOS attack vector with SFC OAM.____ ____ The critical new functionality provided for operators with Active OAM is the honed in focus on troubleshooting continuity of an SFP, trace an SFP , consistency verification of SFP and fault isolation and localizing of a failure within an SFP as well as valuable SFF record TLV, SFF information TLV/Sub-TLV for multiple SFs as hops of SFP or multiple SFs for load balancing using SFP consistency verification procedures.____ ____ Many Thanks!!____ ____ Gyan____ ____ ____ Many thanks in advance, I am just trying to understand.____ ____ Best,____ ____ Carlos.____ ____ 11/19/21午後11:02、Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com> <mailto:hayabusagsm@gmail.com>>のメール:____ ____ ____ Dear Chairs & All ____ ____ As co-author I support publication of this draft. ____ ____ This specification fills a crucial gap for operators for new OAM functionality, with an Active Multi layer OAM model, by defining extensibility with Active OAM messages, in NSH, to troubleshoot faults in the data plane SFC forwarding plane, SFP E2E path in the service plane framework.____ ____ Kind Regards ____ ____ Gyan____ Verizon ____ ____ On Fri, Nov 19, 2021 at 8:33 PM Carlos Pignataro (cpignata) <cpignata=40cisco.com@dmarc.ietf.org<mailto:cpignata=40cisco.com@dmarc.ietf.org> <mailto:40cisco.com@dmarc.ietf.org>> wrote:____ Dear Greg,____ ____ Thank you for replying to my email. Please find a couple follow-ups inline, as I invite other WG interested parties to the discussion.____ ____ 11/19/21午後7:11、Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com>> のメール:____ ____ Dear Carlos,____ thank you for your thorough review and detailed comments. Please find responses in-lined below under the GIM>> tag.____ ____ Regards,____ Greg (on behalf of the authors)____ ____ On Sat, Nov 13, 2021 at 11:50 PM Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com> <mailto:cpignata@cisco.com>> wrote:____ Hello, WG,____ ____ In reviewing draft-ietf-sfc-multi-layer-oam-16, I find that the issues listed below are such that I cannot support publication.____ ____ Observing what appears to be a single non-author response to the original WGLC email, and one more after this extension, I also perceive the energy level to work on this to be low.____ ____ Please find some review comments and observations, I hope these are useful:____ ____ ____ Active OAM for Service Function Chaining____ draft-ietf-sfc-multi-layer-oam-16____ ____ Abstract____ ____ A set of requirements for active Operation, Administration, and____ Maintenance (OAM) of Service Function Chains (SFCs) in a network is____ presented in this document. Based on these requirements, an____ encapsulation of active OAM messages in SFC and a mechanism to detect____ and localize defects are described.____ ____ First, a generic comment on the whole document: Even though the WG produces an SFC OAM framework in rfc8924, I cannot find exactly how draft-ietf-sfc-multi-layer-oam follows or maps to such framework.____ * rfc8924 lists requirements in S4, but this document mentions them in passing. Instead, as per the Abstract above, this document creates new requirements and based on them creates a new OAM protocol.____ GIM>> We've followed the requirements listed in RFC 8924 and used them when designing SFC Echo Request/Reply. SFC Echo Request/Reply addresses the essential requirements in Section 4 of RFC 8924.____ ____ CMP: That’s an issue, those are not requirements for a new protocol. Neither for a single protocol to perform all functions.____ ____ CMP: Specifically, RFC 8924 says:____ ____ CMP: “7. Candidate SFC OAM Tools”____ CMP: Why were candidates descarted? When it is shown how they can address some of the functions.____ ____ ____ * rfc8924 lists candidate SFC OAM tools, but this document does not consider them. Or compare requirements to options. Perhaps I could be pointed to the discussion on the list?____ GIM>> RFC 8924 already provides the analysis and pointed out gaps in listed protocols. RFC 8924 has concluded that none of the available tools complies with the requirements. ____ ____ CMP: I do not see that conclusion in RFC 8924, perhaps you can quote / copy/paste the relevant text. The specific text that includes a conclusion. And specific text that says that none of the tools comply with the requirements.____ ____ CMP: In any case, there is also no implication that creating a new protocol for all requirements and ignoring the analysis of existing protocols that can be used or extended is in the best interest of SFC’s OAM.____ ____ CMP: Additionally, I did not see the discussion on the list of this comparison (since it does not exist in the draft).____ ____ ____ Additionally, I wonder: Why the file name “sfc-multi-layer-oam”?____ GIM>> It is historical. ____ ____ ____ Active OAM tools,____ conformant to the requirements listed in Section 3, improve, for____ example, troubleshooting efficiency and defect localization in SFP____ because they specifically address the architectural principles of____ NSH. For that purpose, SFC Echo Request and Echo Reply are specified____ in Section 6.____ ____ I do not fully follow these cause-consequence pair of sentences. They seem to be foundational to the rational of the document, is this why a new OAM protocol is used?____ GIM>> Indeed. Based on the analysis in RFC 8924, we've learned that none of the available OAM tools can address the requirements for active SFP OAM. The SFC Echo Request/Reply is specifically designed to address these requirements.____ ____ CMP: This is a very useful response. As I responded above, there’s no implication that if no existing tools address all requirements, the path is to create a brand new one ignoring the existing ones.____ ____ ____ Specifically, I feel this document over-reaches in that it presumes that the only “Active OAM” protocol for NSH SFCs is this new protocol, whereas some of the existing protocols listed in rfc8924 are also “Active OAM”.____ GIM>> I think that the document is positioned not as a general active OAM protocol but as one of the active SFC NSH OAM protocols.____ ____ This mechanism enables on-demand Continuity Check,____ Connectivity Verification, among other operations over SFC in____ networks, addresses functionalities discussed in Sections 4.1, 4.2,____ and 4.3 of [RFC8924].____ ____ This could be well the case — however many others (including existing) mechanisms also enable in these broad terms all the connectivity+continuity+trace functions.____ GIM>> We are not questioning that there are other solutions. But these mechanisms are not supported by specifications that ensure independent interoperable implementations. ____ ____ CMP: Can you please point to independent interoperable implementations of draft-ietf-sfc-multi-layer-oam?____ ____ CMP: Part of my point is that any partial solution can be extended interoperably.____ ____ At the same time, this mechanisms is very complex. ____ I would like to see a study of comparative benefits of this added complexity vis-a-vis existing approaches that can be extended.____ GIM>> In the face of absence of sufficient and up to date documentation describing proprietary solutions, I don't see that any comparison can be comprehensive.____ ____ CMP: I am not sure if you are answering a different question, but there’s no reference to any proprietary solutions.____ ____ CMP: ICMP, BFD, iOAM, SFC-Tracceroute, all documented in I-Ds and with open source implementations.____ ____ ____ ____ The ingress may be____ capable of recovering from the failure, e.g., using redundant SFC____ elements. Thus, it is beneficial for the egress to signal the new____ defect state to the ingress, which in this example is the Classifier.____ Hence the following requirement:____ ____ REQ#3: SFC OAM MUST support Remote Defect Indication notification____ by the egress to the ingress.____ ____ I see a gap between “it is beneficial” and “MUST”. What is "Remote Defect Indication” in the context of SFC OAM since it is not in the OAM framework? Is this "Remote Defect Indication” the only way to achieve the rerouting or redundancy triggering?____ GIM>> That is one of possible solutions. Other mechanisms may conform to the requirement using different approach. ____ ____ ____ 4. Active OAM Identification in the NSH____ ____ The O bit in the NSH is defined in [RFC8300] as follows:____ ____ O bit: Setting this bit indicates an OAM packet.____ ____ This document updates that definition as follows:____ ____ O bit: Setting this bit indicates an OAM command and/or data in____ the NSH Context Header or packet payload.____ ____ Active SFC OAM is defined as a combination of OAM commands and/or____ data included in a message that immediately follows the NSH. To____ identify the active OAM message, the "Next Protocol" field MUST be____ set to Active SFC OAM (TBA1) (Section 9.1). ____ ____ This is an example of over-reach. A “Next Protocol” pointing to IPv4, in turn pointing to ICMP, in turn pointing to Echo is already one example of “Active SFC OAM”. I wonder if this new protocol might be best served by choosing a name that is not so generic? It could be called “One of many active SFC OAM protocols” :-) ____ GIM>> Will clarify that throughout the document "active OAM" and "active SFC OAM" refers to specially constructed packets that immediately follow the SFC Active OAM Header (Figure 2).____ ____ CMP: The “SFC Active OAM Header” is therefore not part of the “active SFC OAM” packet?____ ____ ____ Otherwise, the “MUST” in the last sentence seems to not follow.____ ____ The rules for____ interpreting the values of the O bit and the "Next Protocol" field____ are as follows:____ ____ I am extremely concerned about this attempted re-definition (of the O-bit and Protocol fields). On several fronts as explained below. During RFC8300 the WG evaluated these and provided a solution already.____ ____ * O bit set and the "Next Protocol" value does not match one of____ identifying active or hybrid OAM protocols (per classification____ defined in [RFC7799]), e.g., defined in Section 9.1 Active SFC OAM____ (TBA1).____ This potentially breaks the concept of nodes not understanding OAM (i.e,. Partial deployment of a new protocol)____ GIM>> Can you clarify what do you mean by "nodes not understanding OAM"? Partial deployment is, in my opinion, an operational issue. An operator plans deployments of new releases according to new features and their intended use.____ ____ CMP: Apologies, I meant not s/understanding/parsing/.____ ____ CMP: I agree it is an operational issue — an issue of operations. Like the “O” in “OAM”. Should Operational Considerations be included as well?____ ____ ____ - a Fixed-Length Context Header or Variable-Length Context____ Header(s) contain an OAM command or data.____ ____ - the "Next Protocol" field determines the type of payload.____ The semantic of Context Headers is outside this definition. For example the types in MD Type 2 define the variable headers. ____ ____ This potentially breaks also OAM, since things like ECMP can be encoded in context headers that the OAM needs. (e.g., "Flow ID” from draft-ietf-sfc-nsh-tlv).____ GIM>> As I understand it, MD Type 2 Flow ID TLV is recommended to identify a flow in SFC NSH. The document makes the use of this method. ____ ____ CMP: How?____ ____ ____ Further, is this describing a Hybrid OAM use?____ GIM>> No, the document does not describe the use of hybrid OAM (per RFC 7799). ____ ____ * O bit set and the "Next Protocol" value matches one of identifying____ active or hybrid OAM protocols:____ ____ - the payload that immediately follows the NSH MUST contain an____ OAM command or data.____ This is also unclear — what is an OAM command or data? If the O-bit is set, it is an OAM packet.____ GIM>> What is an OAM packet? Is an SFC NSH packet with IOAM an OAM packet or not? If an SFC NSH packet is part of flow under the Alternate Marking, is it an OAM packet because the Alternate Marking method is an example of the hybrid OAM? ____ ____ CMP: This reads like not answering by asking questions. ____ ____ CMP: A user packet with marking, implicitly or explicitly, is not an OAM packet.____ ____ ____ * O bit is clear:____ ____ - no OAM in a Fixed-Length Context Header or Variable-Length____ Context Header(s).____ ____ - the payload determined by the "Next Protocol" field MUST be____ present.____ It is unclear the rational for this.____ GIM>> Can you please clarify your interpretation, so we can look for ways to improve the text?____ ____ CMP: Same as above. It is unclear why these rules. It is not a matter of interpretation.____ ____ ____ * O bit is clear, and the "Next Protocol" field identifies active or____ hybrid OAM protocol MUST be identified and reported as an____ erroneous combination. An implementation MAY have control to____ enable processing of the OAM payload.____ This seems to break the existing usage in draft-ietf-sfc-ioam-nsh. Section 4.2 of draft-ietf-sfc-ioam-nsh says clearly:____ GIM>> I don't see any problem. In fact, both definitions are in sync. According to draft-ietf-sfc-ioam-nsh if the Next Protocol field identifies a use data payload, e.g., IPv6, then O bit MUST NOT be set. If the Next Protocol is set to IOAM, then the O-bit MUST be set.____ ____ CMP: Sorry, but you do not seem to be actually reading draft-ietf-sfc-ioam-nsh. Please refer to:____ ____ CMP: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2 <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2>____ ____ CMP: 4.2. IOAM and the use of the NSH O-bit____ [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300] the O____ bit must be set for OAM packets and must not be set for non-OAM____ packets. Packets with IOAM data included MUST follow this____ definition, i.e. the O bit MUST NOT be set for regular customer____ traffic which also carries IOAM data and the O bit MUST be set for____ OAM packets which carry only IOAM data without any regular data____ payload.____ CMP: Please note the “MUST NOT” in the paragraph immediately above.____ ____ We agree in how O-bit works in presence of IOAM that accompanies user data and without it.____ ____ CMP: I do not see that agreement.____ ____ ____ 4.2. IOAM and the use of the NSH O-bit____ ____ [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300] the O____ bit must be set for OAM packets and must not be set for non-OAM____ packets. Packets with IOAM data included MUST follow this____ definition, i.e. the O bit MUST NOT be set for regular customer____ traffic which also carries IOAM data and the O bit MUST be set for____ OAM packets which carry only IOAM data without any regular data____ payload.____ ____ ____ 5. Active SFC OAM Header____ ____ As demonstrated in Section 4 [RFC8924] and Section 3 of this____ document, SFC OAM is required to perform multiple tasks. Several____ active OAM protocols could be used to address all the requirements.____ When IP/UDP encapsulation of an SFC OAM control message is used,____ protocols can be demultiplexed using the destination UDP port number.____ But extra IP/UDP headers, especially in an IPv6 network, add____ noticeable overhead. This document defines Active OAM Header____ (Figure 2) to demultiplex active OAM protocols on an SFC.____ ____ Does this paragraph imply that the main reason for this protocol is this perceived overhead? If so, experience seems to show that in practice IP-encaped OAM works fine (as e.g., for LSP Ping). ____ GIM>> Isn't IP/UDP encapsulation, and IPv6 in particular, is a larger overhead? ____ ____ CMP: I am sorry Greg to call this out, but you are choosing again to not answer the question and instead ask another one.____ ____ CMP: I am happy to answer: it is larger. It also does not matter. And further it is proven to work in LSP Ping.____ ____ CMP: My question again: is the whole purpose of this new protocol to be overhead efficient? I am sure there are ways of encasulating that are more overhead-efficient than draft-ietf-sfc-multi-layer-oam.____ ____ ____ Alternatively, “Next Protocols” could be defined for “raw” existing protocols.____ ____ Msg Type - six bits long field identifies OAM protocol, e.g., Echo____ Request/Reply or Bidirectional Forwarding Detection.____ ____ Why does BFD get encapsulated in this new protocol, as opposed to using a “Next Protocol” for it? That looks like unnecessary overhead and indirection.____ GIM>> Are you proposing assigning different Next Protocol values for every possible active OAM protocol? ____ ____ CMP: I am not proposing anything. I am simply asking a question.____ ____ ____ Flags - eight bits long field carries bit flags that define____ optional capability and thus processing of the SFC active OAM____ control packet, e.g., optional timestamping. ____ Does this timestamp conflict with context header timestamps? E.g., rfc8592 or draft-mymb-sfc-nsh-allocation-timestamp.____ GIM>> What do you see as a potential conflict? ____ ____ CMP: Two timestamps in different parts of a packet.____ ____ ____ 6. Echo Request/Echo Reply for SFC____ ____ Echo Request/Reply is a well-known active OAM mechanism extensively____ used to verify a path's continuity, detect inconsistencies between a____ state in control and the data planes, and localize defects in the____ data plane. ICMP ([RFC0792] for IPv4 and [RFC4443] for IPv6____ networks, respectively) and [RFC8029] are examples of broadly used____ active OAM protocols based on the Echo Request/Reply principle. The____ SFC Echo Request/Reply defined in this document addresses several____ requirements listed in Section 3. Specifically, it can be used to____ check the continuity of an SFP, trace an SFP, or localize the failure____ within an SFP. The SFC Echo Request/Reply control message format is____ presented in Figure 3.____ ____ This seems to be an important paragraph — would be useful to also understand how other existing and broadly used protocols cannot fulfill requirements.____ GIM>> RFC 8924 already provided a comprehensive analysis and concluded that none of the available tools can fully conform to the requirements listed in Section 4. ____ ____ CMP: As per above, I do not see that conclusion.____ ____ CMP: And frankly even if that was the case, there’s no implication that using the existing pieces is not sufficient, or that it is not easier to extend the candidate protocols.____ ____ ____ Length - two-octet-long field equal to the Value field's length in____ octets.____ ____ There are several nested lengths defined in this document — would be useful to analyze that they do not result in issues such as piggybacking unaccounted data.____ GIM>> Do you see any scenario when that might be the case? ____ ____ 6.3.1. Source TLV____ ____ Responder to the SFC Echo Request encapsulates the SFC Echo Reply____ message in IP/UDP packet if the Reply mode is "Reply via an IPv4/IPv6____ UDP Packet". Because the NSH does not identify the ingress node that____ generated the Echo Request, the source ID MUST be included in the____ message and used as the IP destination address and destination UDP____ port number of the SFC Echo Reply. The sender of the SFC Echo____ Request MUST include an SFC Source TLV (Figure 5).____ ____ This seems to negate the benefit of less overhead, if the IP/UDP fields are embedded as OAM TLVs.____ GIM>> Only the Source ID is required, not the whole set of IP and UDP headers. ____ ____ This also seems to be a bit of an invitation for an attack.____ ____ ____ 6.4.1. Errored TLVs TLV____ ____ I wonder at this point if it is easier to use LSP Ping directly instead of re-define it.____ GIM>> If someone wants to explore that option, of course. ____ ____ 6.5.1. SFC Reply Path TLV____ …____ * Service Index: the value for the Service Index field in the NSH of____ the SFC Echo Reply message.____ How is the service index in a reply constructed?____ GIM>> It is provided by the sender of the SFC Echo Request. ____ ____ CMP: Does this mean it skips hops? Apologies I do not understand.____ ____ ____ ____ 6.5.3. SFC Echo Reply Reception____ ____ An SFF SHOULD NOT accept SFC Echo Reply unless the received message____ passes the following checks:____ ____ * the received SFC Echo Reply is well-formed;____ ____ * it has an outstanding SFC Echo Request sent from the UDP port that____ matches destination UDP port number of the received packet;____ ____ Is the demultiplexing based on UDP, OAM handle, or combination?____ GIM>> The values of the Sender's Handle and Sequence Number fields can be used.____ ____ CMP: I understand several values can be used.____ CMP: Which one is actually used?____ CMP: If the Handles and sequences match but not the port?____ ____ ____ 6.6. Verification of the SFP Consistency____ * Collect information of the traversed by the CVReq packet SFs and____ send it to the ingress SFF as CVRep packet over IP network;____ ____ What if NSH is not over IP?____ GIM>> Then the operator will specify another method using the Reply mode. ____ ____ CMP: Sorry that does not answer my question. The text in question is not contextual to a specified reply mode.____ ____ ____ SF Type: Two octets long field. It is defined in [RFC9015] and____ indicates the type of SF, e.g., Firewall, Deep Packet Inspection, WAN____ optimization controller, etc.____ ____ Is RFC 9015 a hard dependency to implement this OAM? ____ GIM>> RFC 9015 established the IANA registry of SF Type and any new SF types must be registered.____ ____ IANA is requested to assign a new type from the SFC Active OAM____ Message Type sub-registry as follows:____ ____ +=======+=============================+===============+____ | Value | Description | Reference |____ +=======+=============================+===============+____ | TBA2 | SFC Echo Request/Echo Reply | This document |____ +-------+-----------------------------+---------------+____ ____ Is there a single value for both Request and Reply?____ GIM>> Yes, it is a single value. Echo Request and Echo Reply are identified in the Message Type field (Figure 3). ____ ____ CMP: Is this document defining a full 64k space for a single value? If so it appears to be wasteful.____ ____ ____ 9.2.1. Version in the Active SFC OAM Header____ 9.3.1. SFC Echo Request/Reply Version____ ____ There seems to be a version for the OAM and a version for the msg type. Is this correct? Are they hierarchical versions? Or independent? ____ This seems to overly complicate parsing and compliance.____ GIM>> All versions are independent. ____ ____ CMP: This seems like an operational unnecessary complexity, in keeping a matrix of supported combination of versions. If there was an Operational Considerations section, this should be included.____ ____ ____ 9.3.3. SFC Echo Request/Echo Reply Message Types____ Does this mean that there’s a protocol number for “Active OAM” with a protocol number for “Request/Reply” with a protocol number for either request or reply?____ GIM>> These are not all protocol numbers. Only the Active OAM is a new protocol number. Others are message types. ____ ____ CMP: Apologies I was not clear.____ CMP: The “SFC Active OAM” is actually a "SFC Next Protocol”.____ CMP: My intention of using “protocol number” is in a generic way. To get to some OAM function, a node needs to recursively parse 3 TLVs. Correct? This seems overly complex.____ ____ ____ Values defined for the Return Codes sub-registry are listed in____ Table 14.____ ____ Various values in this table are not defined in the document. The procedures seem lacking.____ GIM>> Other specifications may define additional code points in the registry. ____ ____ CMP: Thank you. The procedures still seem lacking.____ ____ CMP: Best,____ ____ CMP: — Carlos.____ ____ ____ 9.7. SF Identifier Types____ This document seems to be creating a space for identifying SFs — which I thought was mostly outside the scope of OAM to test SFs. ____ GIM>> The registry is of SF Identifiers, not of SF Types (that already exists). Hope that clarifies the issue. ____ ____ Does this further imply that there’s a new requirement to have unique identifiers within the domain for all SFs?____ ____ I hope these comments and review questions and concerns are useful for the WG discussion and consideration.____ ____ Thanks,____ ____ Carlos.____ ____ ____ Nov 1, 2021 2:50 PM、 Joel Halpern Direct <jmh.direct@joelhalpern.com<mailto:jmh.direct@joelhalpern.com> <mailto:jmh.direct@joelhalpern.com>> のメール:____ ____ I have received a polite request with explanation for delay asking for more time to read and review the subject document. Given the state of the working group, i want to encourage any and all review. So I am extending the last call by two additional weeks. Please read and review the document. Also, if you are willing to serve as shepherd for this, please let the chairs know. (Don't worry if you have not shepherded a document before. The chairs are more than happy to help you with the process.) Thank you, Joel _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> <mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>____ ____ _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> <mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>____ --____ <image001.jpg> <http://www.verizon.com/>____ *Gyan Mishra*____ /Network Solutions Architect /____ /Emailgyan.s.mishra@verizon.com<mailto:Emailgyan.s.mishra@verizon.com> <mailto:gyan.s.mishra@verizon.com>/____ /M 301 502-1347/____ ____ ____ --____ <image001.jpg> <http://www.verizon.com/>____ *Gyan Mishra*____ /Network Solutions Architect /____ /Emailgyan.s.mishra@verizon.com<mailto:Emailgyan.s.mishra@verizon.com> <mailto:gyan.s.mishra@verizon.com>/____ /M 301 502-1347/ <Diff_ draft-ietf-sfc-multi-layer-oam-17.txt - draft-ietf-sfc-multi-layer-oam-18.txt.html> _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc
- [sfc] Regarding last call for draft-ietf-sfc-mult… Joel Halpern Direct
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Dirk.von-Hugo
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Donald Eastlake
- Re: [sfc] Regarding last call for draft-ietf-sfc-… wei.yuehua
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Gyan Mishra
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Gyan Mishra
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Gyan Mishra
- [sfc] SFC OAM gap analysis [Was Re: Regarding las… Greg Mirsky
- Re: [sfc] SFC OAM gap analysis [Was Re: Regarding… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Frank Brockners (fbrockne)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Frank Brockners (fbrockne)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Linda Dunbar
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Frank Brockners (fbrockne)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Frank Brockners (fbrockne)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Dirk.von-Hugo
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Huzhibo
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Frank Brockners (fbrockne)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Frank Brockners (fbrockne)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Joel Halpern Direct
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Greg Mirsky
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Joel Halpern Direct
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Carlos Pignataro (cpignata)
- Re: [sfc] Regarding last call for draft-ietf-sfc-… Joel M. Halpern
- Re: [sfc] Regarding last call for draft-ietf-sfc-… mohamed.boucadair